dfu-programmer build experience

[ilg-ul]

After successfully building the toolchain, I needed a solution to program the AVR32, and so I reached dfu-programmer. I have now a functional solution, but it required some work.

The first test I did used the MacPorts package. Unfortunately it is based on 0.5.2, and this version has a bug, not being able to ignore the trampoline code (after manually removing the first 0x2000 bytes, the tool has no problem to program the flash).

The bug was known, documented and fixed in 0.5.4, so I gave this version a try, doing the build myself.

Everything went fine, the build completed without problems and the resulting program was functional, even when the trampoline code was present.

The only problem I can mention is the reference to libusb, missing in the Apple distribution. Running the build after adding MacPorts to the PATH fixed the reference.

At the end I also tried to build the dfu-programmer with your Makefile, but in my environment this seems not possible. My avr32 build environment includes a reference to Homebrew, installed in /brew/local, and does not include any reference to MacPorts, installed in /opt/local. Although installing libusb in Homebrew was no problem at all, I did not find a way to configure the dfu-programmer build to reference the /brew/local folder, and I would like to avoid including MacPorts in the build too.

So, in case you decide to continue work on the Makefile and include the part to build dfu-programmer, we'll probably need to patch the configuration script, to allow linking to a separate folder Homebrew installation.

Liviu

[ilg-ul]

For just in case, I filed a feature request to the dfu-programmer tracker, asking for a configurable libusb location, but if we could suggest a patch for this, the chances of seeing it happen would increase.

Liviu

[jsnyder]

Thanks for all the reports you've been filing. This will help nail down the holes in this toolchain build and get it to a more robust state.

I've wanted to include dfu-programmer, but I hadn't gotten around to deciding what to do about libusb. I don't mind patching for what you're describing for the time being since that's a non-platform-specific fix. It sounds like we can also just update PATH for now though? I'm going to work through fixing some of the other bugs you've filed before getting to this one specifically.

[ilg-ul]

It sounds like we can also just update PATH for now though?

I thought about this too, but this doesn't seem possible, in my case libusb is in /brew/local/lib and the headers are in /lib/local/include, I don't know how to update the PATH to accommodate this.

Ideally the configure script should have an option like --with-libusb=/brew/local, like the options used by gcc.

I'm going to work through fixing some of the other bugs you've filed before getting to this one specifically.

ok, just let me know when new versions are available and I'll give them a try.

Liviu

p.s. BTW, I migrated my entire development from a Windows VM to Mac OS, and... the AVR32 application built successfully :-)

[jsnyder]

I thought about this too, but this doesn't seem possible, in my case libusb is in /brew/local/lib and the headers are in /lib/local/include, I don't know how to update the PATH to accommodate this. Ideally the configure script should have an option like --with-libusb=/brew/local, like the options used by gcc.

Ah, I got the impression that adjusting the path was workable given it sounds like it worked for MacPorts, although perhaps you meant that there was an edit to dfu-programmer's build system to include that in the path?

Ideally, yes, --with-libusb would be a nice option.

Also, however, libusb is, from previous experience, not actually that big of a pain to build so I wouldn't be above static linking or somehow including it in the build because otherwise binary builds of this whole thing will be a problem (thus why it isn't a default part of the build). I have to look into this more. At the moment, I believe my binary builds should work on OS X and 64-bit Linux for the most part without specially installed dependencies, libusb changes this a little (mpc, mpfr & gmp are only required at build time, from my recollection).

I'm glad to hear that you've got a working toolchain under OS X. This is, of course, what motivated me to put together these Makefiles: making it not horribly painful to build and update a full working toolchain on OS X :-)

I've a bit busy and AFK this weekend so I'll try and start addressing them through the week as time allows.

[ilg-ul]

I got the impression that adjusting the path was workable given it sounds like it worked for MacPorts

that is correct, adding /opt/local/bin:/opt/local/sbin to the path worked, adding /brew/local/bin didn't (there is no /brew/local/sbin). it looks like configure is running some program to enumerate the libraries, and this program is missing on Homebrew. If we can identify it, I don't mind adding a package to Homebrew and updating the PATH.

otherwise any simple solution is fine with me, as long as I can use the separate folders with Homebrew or MacPorts.

Liviu