All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH RFC] Fix avr32 build using internal toolchain
Date: Sun, 20 Jan 2013 15:21:52 +0100	[thread overview]
Message-ID: <20130120152152.31628abb@skate> (raw)
In-Reply-To: <CAHt8ZCOH9FgqzkB2KHJSSBc3k76-07iYNfsQ_rjzQCzOFGLEAg@mail.gmail.com>

Dear Simon Dawson,

On Sun, 20 Jan 2013 11:01:30 +0000, Simon Dawson wrote:

> Yes, I'm using Buildroot for the continued development of a system
> based on the Atmel ap7000. This system will be under
> development/support for at least the next few years, I would imagine.

Ok.

> Yes, I think we discussed this briefly at the Buildroot Developer Days
> in Barcelona. My understanding is that avr32 is regarded
> semi-officially as an end-of-life architecture. Atmel technical
> support are, for the time being, still dealing with support queries
> for avr32.
> 
> > Therefore, I'm wondering if we shouldn't mark this architecture as
> > deprecated.
> 
> From my own perspective, I'd rather keep the avr32 support in
> Buildroot for now. I don't know how many other people are using the
> architecture --- not that many, I suspect. Would that be a major
> problem?

Long term it is a problem to have a gcc 4.2.x only toolchain and an old
uClibc version. Some packages will fail to build because gcc is too
old, we'll start depending on some uClibc features that the old uClibc
version does not have, etc.

> I don't know how much effort would be involved in migrating to newer
> gcc, binutils and uClibc; have you any idea?

I know OpenWRT has some AVR32 support patches for more recent gcc
versions (maybe gcc 4.5 or something, I don't remember). I tried once
using them, but it wasn't straightforward, and I didn't want to spend
too much time on AVR32, honestly :)

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  parent reply	other threads:[~2013-01-20 14:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-17 22:16 [Buildroot] [PATCH RFC] Fix avr32 build using internal toolchain spdawson at gmail.com
2013-01-19 10:38 ` Thomas Petazzoni
2013-01-20 11:01   ` Simon Dawson
2013-01-20 12:54     ` Gustavo Zacarias
2013-01-20 13:22       ` Simon Dawson
2013-01-20 14:22         ` Gustavo Zacarias
2013-01-20 21:24           ` Simon Dawson
2013-01-20 14:21     ` Thomas Petazzoni [this message]
2013-01-20 21:23       ` Simon Dawson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130120152152.31628abb@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.