I work with upstream buildroot when I have the time to, from where atmel feels free to pull changes from, which is perfectly ok and desireable. We also try to support AVR32 in the upstream project, but the high number of patches makes it dificult.
Not mentioning the gcc soup opera, I found today that openssl is in similar situation.
The openssl patch is unclean, it touches way more files than just necessary to add des-avr32.S and aes-avr32.S as suggested by it's naming. This makes the patch not to apply cleanly anymore.
It could be solved by submiting your changes upstream. You should not try to maintain everything on your own when you can offset some development to the upstream projects.
In the current Atmel's buildroot, you are using version g in the patch while there is a version k that fixes several important security issues.
There is not even a mention of "AVR32" in any of the openssl mailing lists . Which suggests no one has even attempted to submit it upstream, even after having this patch for so long.
The only reason I'm wasting my time on this is to try to make this platform support the best possible, I'm sure your goals are the same as well. You guys have made a great job so far, but failing to take this last step makes your work outdated in very short amount of time.
PS: A copy of this post is going to support.atmel.no in an attempt to reach Atmel developers. Users, you can show your support replying.
Thiago A. Correa