For some reason, Atmel seems reluctant to submit avr32 support mainline. Since these patches are generally fairly version-specific, it seems logical to have separate packages for them entirely. Patches: http://distribute.atmel.no/tools/opensource/avr32-gcc/ Note that avr32 and avr are entirely different targets! I have successfully built and run a firmware built with this, but it crashes when it tries to write to USB too fast. I have not yet determined the fault for this. == binutils == Merely adding patches to /etc/portage/patches/cross-avr32/binutils/ is not sufficient, as autotools needs to regenerate stuff, plus some 'make headers' step for bfd. Additionally, a symlink to ldscripts is expected in the avr32 root (/usr/avr32), which interferes with multislot. I have this working in my overlay (layman -a luke-jr), except multislot. == gcc == Throwing the patches in /etc/portage/patches/cross-avr32/gcc/ gets it building with the normal ebuild. == atmel-headers == These are available as a ZIP containing both avr and avr32 headers. My overlay has an ebuild that installs only the appropriate ones based on the category. == newlib == Additionally, newlib requires patching (and autoreconf), and does not support the /etc/portage/patches structure at all. I have 1.20 building from my overlay.
(In reply to Luke-Jr from comment #0) > For some reason, Atmel seems reluctant to submit avr32 support mainline. > Since these patches are generally fairly version-specific, it seems logical > to have separate packages for them entirely. > Patches: http://distribute.atmel.no/tools/opensource/avr32-gcc/ Seems to be unavailable. > == binutils == > Additionally, a symlink to ldscripts is expected in the avr32 root > (/usr/avr32), which interferes with multislot. bug #147155
