Clark, Rob wrote:
Also, I wonder if we should split #linaro, either into #linaro-devel
and leave #linaro as a place that users can come to for help, or setup
a separate #linaro-users? This way we aren't just dumping out new
releases with nowhere for users to turn to for help.. (Well, they can
Clark, Rob wrote:
just some random thoughts on our release model, etc.. I've been
meaning to write up for a while but haven't had time
[+1] :)
Actually, the issue isn't as much with Ubuntu as with Android.
For Ubuntu, I have stopped pointing people at Linaro and always
advise them to use off
Mike Hommey wrote:
On Tue, Aug 09, 2011 at 07:32:51PM -0300, Christian Robottom Reis wrote:
On Tue, Aug 09, 2011 at 03:08:53PM -0700, Taras Glek wrote:
> >You should definitely be trying to build using the Linaro 4.5 and 4.6
> >compiler branches; they are pretty much guaranteed to give you
Bernhard Rosenkranzer wrote:
Hi,
while working on some improvements, I noticed that our Android
toolchain binaries are built as 32-bit x86.
Is there any reason for this (other than "we inherited it from AOSP")?
While it doesn't matter much, it doesn't make much sense to me -
Android can't curren
Dechesne, Nicolas wrote:
On Thu, Jun 30, 2011 at 9:24 AM, Vladimir Pantelic mailto:vlado...@gmail.com>> wrote:
would you be able to come up with a short list of "fixes" that have been
done?
the notable problem fixed in OMAP4 vs OMAP3 boot code is related to how the ROM
Dechesne, Nicolas wrote:
ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in
OMAP4 stuff seems pretty much perfect for
SD Card boot case, it doesn't care about any arcane stuff like geometry for
example. It only needs to success to
pull MLO reliably and anythi
Andy Green wrote:
I think we can count that as arcarna... but I think we're talking about
different problems, and that the ROM fragility to partitioning on OMAP3
is real enough.
On an IGEP0020 I was unable to create a bootable image -- one that would
boot x-loader so it would talk on the serial
Andy Green wrote:
ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in
OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't
care about any arcane stuff like geometry for example. It only needs to
success to pull MLO reliably and anything further can be don
Måns Rullgård wrote:
> Mandeep Kumar writes:
>
>>> Vladimir Pantelic writes:
>>> > Either I am doing something wrong or this libjpeg-turbo is not so turbo.
>>>
>>> Libjpeg (turbo or regular) is full of inefficiencies. I guess they all
>&g
Mandeep Kumar wrote:
Hi All,
I have done some benchmarking on OMAP4 running Ubuntu for various versions of
libjpegs. Benchmarks were collected with
modified version of djpeg that prints out ms time taken for decoding. Sample
used for benchmarking is a 12MP image
downloaded from a photography
On 06/24/2011 08:13 PM, Woodruff, Richard wrote:
This suggests to me that a simple drop-in of libjpeg-turbo might
be actually easy to do, and that there is probably a significant
performance benefit to be achieved. One thing to keep in mind is
that this code still supports armv6, so we'd probabl
11 matches
Mail list logo
