Re: AVR32 support in crosstool-ng

[Martin Guy <martinwguy at gmail dot com>]

On 29 April 2013 22:11, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> On 4/29/2013 2:49 PM, Martin Guy wrote:
>> On 29 April 2013 20:29, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>>> As an embedded FOSS community, we need to be encouraging
>>> vendors.. prodding them.. to submit their tools upstream.
>>
>> Absolutely. After all, chip vendors make their money by selling
>> silicon, not compilers.
>
> Agreed.

Sorry, I wasn't very clear here.

What I mean is that chip vendors make money by selling silicon.
To sell silicon, other companies have to decide to use the vendor's
chips in new products, the choice of chip is influenced by their
software developers' recommendations and good compiler support is a
major factor for a software developer.

Here's our story:
  Our company had chosen AVR32 for its price/performace ratio and for
its GNU toolchain. After a year of development, we lost two whole
months, right before the product launch, chasing a bug that made the
completed software product freeze, apparently at random. It turned out
to be due to a bug in all the AVR32 toolchains, that had been fixed
years ago in a newer version of newlib. Not even in GCC. In
newlib-1.16.
  As soon as I'd fixed that bug, another one showed up with the same
symptoms: that the product runs for a bit then freezes. We didn;t
bother investigating that, but distributed the product with the last
binary versions of the s/w that had never been known to freeze. We
stopped software development for that product because we couldn't
guarantee to produce reliable firmware without another series of
months chasing phantom toolchain bugs.
  The only reason I am struggling now with AVR32 GCC support is hoping
to get a working compiler is to make a one-year-later update to the
firmware for the old product. Atmel's compilers are still distributed
with broken newlib. Management are telling me not to waste my time, as
they have only lost money on the old product.
  They are now a bit funny in the head about Atmel chips, having been
in hell for two months last year. They say the AVR32 is "dead and
abandoned by Atmel". They were all ready to make the next product with
PIC32, and asked me to evaluate the compiler support. There are GNU
toolchains for PIC32. Microchip distribute have a free version with
optimization turned off and they make you link to a closed-source
binary object file to perform chip setup (crt0.o, if you like) with
dire warnings about what will happen to you if you reverse engineer
it. That's about as far as you can get bending the GPL without
breaking it.
  So we dumped the PIC32 project, despite having already done the
routing for the main board, and their next product will be based on
ARM, who have been investing heavily in open source software tools and
operating systems for years. Lord, a cross-toolchain for ARM is now
even included in Ubuntu.
  Not that I like ARM's world-domination and would much rather support
open hardware and CPU diversity. But when it comes to the difference
between fifteen different high-quality recent toolchains and an
ancient one full of bugs or one that mandates binary blobs... that is
life or death to the product.
  I'm doing what I can for Atmel, or rather for its users. I did the
same for Cirrus (or rather, their users) a few years back. Atmel seems
to be making moves int hat direction, but doesn't really understand
open source. Not the way ARM does.

> As a community, we just aren't doing a good job of selling the idea that
> merging and maintaining benefits both sides. It has to be cheaper to keep
> it up to date and tested versus jumping 4 or 5 major gcc versions. But it is
> cheaper to do the port, throw it to users and walk away.

Cheaper, maybe, but less profitable.

   M

--
For unsubscribe information see http://sourceware.org/lists.html#faq