From: Bryan Hundven <bryanhundven@gmail.com>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Future plans for uClibc-ng?
Date: Sun, 3 Jan 2016 01:35:26 -0800 [thread overview]
Message-ID: <20160103093526.GB25330@hp2000d> (raw)
In-Reply-To: <20160103092726.GW30206@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1746 bytes --]
Robert,
On Sun, Jan 03, 2016 at 10:27:26AM +0100, Robert Schwebel wrote:
> On Sat, Jan 02, 2016 at 06:02:37PM -0800, Bryan Hundven wrote:
> > > > I'm curious to know if ptxdist/OSELAS.Toolchain plans to support
> > > > uClibc-ng in the future?
> > > >
> > > > http://www.uclibc-ng.org/
> > >
> > > with half a year without commit to uClib git I'm considering it a dead
> > > project (I failed to verify mailing list activity as neither Firefox
> > > nor IE (!) allowed me to enter archives). uClibc-ng should be relatively
> > > easy to support as config system remained the same... Just tried and
> > > succeded. But are there any active uClibc users?
> >
> > Well, I use it for a few platforms. And I get a lot of requests for it's
> > support on crosstool-ng.
>
> We also use uclibc, especially for uCLinux systems. A few years ago, we
> mainlined Cortex-M3 support. It never gained business traction so far,
> because the BoM for a system is more expensive and less powerful than
> the cheaper systems with mmu (like Atmel 9x25, TI AM335, FSL MX23 etc).
> We still maintain EFM32 in the kernel.
Specifically, I still mess around with the EFM32 port, which is why this
was an interest. Although I realize it is not a focus of pengutronix.
But being able to turn on and off parts of uClibc/uClibc-ng also helps to
shrink the user-space footprint on other systems as well.
> However, these days we are seeing more and more Cortex-A cpus emerging
> with Cortex-M coprocessors. With these devices, running Linux on both
> cores is a real option (as far as I know, this is already implemented
> for Vybrid).
>
> So uClibc stays relevant and will continue to be in OSELAS.Toolchain.
Indeed.
-Bryan
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 91 bytes --]
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
next prev parent reply other threads:[~2016-01-03 9:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-31 20:48 Bryan Hundven
2016-01-02 21:49 ` Ladislav Michl
2016-01-03 2:02 ` Bryan Hundven
2016-01-03 9:27 ` Robert Schwebel
2016-01-03 9:35 ` Bryan Hundven [this message]
2016-01-03 9:27 ` Alexander Dahl
2016-01-03 11:10 ` Ladislav Michl
2016-01-04 14:08 ` Michael Olbrich
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=20160103093526.GB25330@hp2000d \
--to=bryanhundven@gmail.com \
--cc=ptxdist@pengutronix.de \
--cc=r.schwebel@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox