#157

which module?

hold the key next to the usb port when powering up. connect the USB programmer cable prior to powering up.

#158

Teletype, I am trying to install the firmware for the first time, and the process seems a bit more complicated than what I am used to,

#160

i’ve managed to set up github actions to build avr32 toolchain and build firmware:

if you open the link you should see 2 artifacts: the tools and the built ansible firmware. i should mention that for public repos github actions and storing artifacts is free.

i’ve updated my fork of avr32_toolchain repo in the process which i think should fix some of the errors reported earlier (i also had to modify one of the download commands in my fork, was getting a cert mismatch error).

this is not a replacement for setting up the toolchain locally however - yet. it takes about 20 minutes to do a full build since it has to build the toolchain each time. this time can be shortened by just storing the built toolchain (~400Mb) somewhere. what i did was take advantage of the fact that you can create artifacts and have separate actions - so you would only need to build the toolchain once (or, more accurately, every 90 days since that’s the max time github allows for storing artifacts in public repos, still not bad). but i ran into another issue and hoping somebody with more knowledge of bash could help me figure it out.

it downloads and unpacks the toolchain artifact, but when it tries to build the firmware it shows this:

CC      ../main.o
make: execvp: avr32-gcc: Permission denied
make: *** [../main.o] Error 127
../libavr32/asf/avr32/utils/make/Makefile.avr32.in:402: recipe for target '../main.o' failed

i assume it has something to do with permissions on the unpacked toolchain files? how can i fix it? it runs fine if i use the toolchain after generating it as part of the same job.

2 Likes
#161

this is brilliant, thank you. i’ll check out the scripts, though my bash skills are only moderate. @simonvanderveldt and @ngwese are wizards at this stuff, however.

1 Like
#162

Looking at the GH action setup my guess would be that the tool chain build job and the firmware build job are running on different VMs. Since the second VM doesn’t have the packages installed on the first VM the avr32-tools artifact is missing some runtime dependencies.

TBH what might make the most sense here is packaging up the avr32 tool chain as a container (similar to how the norns kernel cross compilation is setup)… then building is just pulling down the container and going. I can help if you’d like to get a similar setup running. It would have the side benefit of creating a stable tool chain for local builds as well (using docker)

2 Likes
#163

Hi all, not about much at the moment (plague / childcare, etc, etc).

Just a quick infodump. If you’re planning on using a container, you might have an easier time just using the Atmel provided binaries we’re currently using with Travis:

See the install section of the .travis.yml file.

From what I recall the Atmel binaries are slowly starting to bitrot, so while they work just fine in the older Ubuntu distro that Travis uses as default they might not work in newer distros. AFAIK they are statically compiled so it might be quite a trivial fixup with patchelf or LD_LIBRARY_PATH.

It might even be worth having a go to see if the binaries work in the GitHub action environment. Otherwise just pick a slightly older distro for the container.

Hope that’s helpful.

1 Like
#164

+1 :slight_smile:

@scanner_darkly If you want/need some help just let me know. Can use the norns discord chat as well if that’s quicker :slight_smile:

1 Like
#165

yeah, they are separate jobs, so each starts with a new image. my thinking was that i could do the toolchain set up in one and then i’d just need to transfer avr32-tools folder (as an artifact) to the 2nd job. i’m realizing now that the toolchain set up also likely installs other tools which is what i’m probably missing. i need to go over the avr32_toolchain makefile and check what else i need to transfer to the 2nd job.

we do have a docker container created by @Dewb: https://github.com/Dewb/monome-build which uses the same avr32_toolchain script (and adds teletype specific tools as well). or do you mean some way to take a snapshot of a container with the toolchain already installed? this would address the possible issue of bitrot.

d’oh! totally forgot we had this already. here i am, reinventing the wheel :)) i’m going to try porting it to github actions.

github actions currently offers:

Ubuntu 20.04 ubuntu-20.04
Ubuntu 18.04 ubuntu-latest or ubuntu-18.04
Ubuntu 16.04 ubuntu-16.04

i’ll try it with 20.04.

#166

Yeah, start with 20.04 and work your way backwards. It seems as though the default Travis Ubuntu is 16.04.

#167

it works! https://github.com/scanner-darkly/multipass-actions-experiments/actions/runs/411579980

i tried 20.04 and it seems fine. confirmed the actual firmware works. the job is actually faster too, this run completed in 35sec, which makes it possible to even use it as a replacement for local set up when needed.

this could also simplify things like creating releases or having an easier way for people to customize. should be easy to set up a fork that would reapply a patch and build a firmware whenever the upstream repo is updated.

2 Likes
#168

was trying to setup the toolchain today and i ran into this. seems like a problem with the atmel server? is there a way around this or will this probably just resolve itself soon enough?

image
image1364×954 208 KB

#169

it’s not available from atmel anymore, use this instead: https://github.com/denravonska/avr32-toolchain

#170

Hmmm so I just gave that a shot, substituting that repo for the old monome one in the instructions at https://github.com/monome/libavr32 and when i ran PREFIX=$HOME/avr32-tools make install-cross, it got 2 errors:

image
image1364×1150 442 KB

#171

you’re likely missing other needed tools. you have to follow the instructions in the repo i linked instead of the ones in libavr32 repo.

you can also use @dewb’s docker image as a reference for what else is needed: https://github.com/Dewb/monome-build/blob/master/Dockerfile

alternatively, you can use https://github.com/monome/avr32-toolchain-linux and the set up steps described in the OP here (or take a look at my github actions, they’re for multipass but the toolchain set up is the same: https://github.com/scanner-darkly/multipass-actions-experiments/blob/main/.github/workflows/build_firmware.yml)

#172

Hmm… well I tried following the instructions at that repo but I get the same two errors when I try and build it (even after a make clean).

I don’t really know anything about docker images or github actions, but I’m good at following a sequential list of commands to type into the terminal! :confused:

#173

sorry - same here, i don’t have enough knowledge about the process, i got it working using the instructions i linked (for github actions, for my local dev i did the set up a long time ago when atmel headers were still available). hopefully somebody else will chime in.

as a temporary workaround, do try the github action option - it’s free and it’s fast enough that you could even use it instead of a local toolchain.

#174

your github actions are linux-specific tho, right? i’m on macOS Catalina.

#175

yes, it’s for linux. i use windows, no experience with mac, so you’ll need to try and apply the instructions from https://github.com/denravonska/avr32-toolchain. have you seen this section there? (messed up formatting in their readme makes it difficult to see somewhat):

=== Requirements (OS X) ===

You will need to have GCC, make and binutils on your machine to compile all of this. You can get all of these on Mac OS X, by just installing the Apple link:http://developer.apple.com/technologies/tools/[Developer Tools]. You should be able to download free versions of 3.x from the ADC website, install from the OS X install disc that came with your machine, or download XCode 4 from the App Store (now free again for all registered users).

You will also need gmp, mpfr and mpc first. I recommend installing these from link:https://github.com/mxcl/homebrew[homebrew] for now. I’ll add these to the Makefile once I have a consistent configuration that can be used for both Linux & OS X.

With homebrew you can install those dependencies like this:
brew install mpfr gmp libmpc texinfo

If you would like to build dfu-programmer, also install libusb:
brew install libusb-compat

#176

yeah… i did some poking around and its the same instructions that are on the original repo that hasn’t been updated in 8 years so I’d assume a lot of stuff could’ve changed with mac dev tools since then that would break it. i also tried the variant where you set gcc to 4.2 or something, but it still had one error that I wouldn’t even begin to know how to solve. :frowning:

#177

Just use Docker, no point in trying to get all this stuff to run on your own machine, it’ll just be a pain.