On Tue, Jan 18, 2011 at 5:49 PM, Michael Hope wrote:
> On Fri, Jan 14, 2011 at 12:31 PM, Khem Raj wrote:
>> Hi
>>
>> There is another ICE which is happening when compiling libcstdc++ for x86
>> Attached testcase you will be able to reproduce this problem
>> by compiling
>>
>> cc1plus a.i -Os -mar
On Fri, Jan 21, 2011 at 05:20:57PM -0500, Nicolas Pitre wrote:
> The only solution in that case is to give top priority to the FIFO IRQ
> and never disable IRQs when in interrupt context, except for that FIFO
> servicing handler which should keep IRQs masked out throughout. In any
> case this w
On Fri, 21 Jan 2011, Russell King - ARM Linux wrote:
> On Fri, Jan 21, 2011 at 02:59:35PM -0500, Nicolas Pitre wrote:
> > On Fri, 21 Jan 2011, Pawel Moll wrote:
> >
> > > VE suffers from serious problem with MMC transfers - low performance,
> > > errors when other IO peripherals (especially USB)
On Fri, Jan 21, 2011 at 02:59:35PM -0500, Nicolas Pitre wrote:
> On Fri, 21 Jan 2011, Pawel Moll wrote:
>
> > VE suffers from serious problem with MMC transfers - low performance,
> > errors when other IO peripherals (especially USB) are used at the
> > same time etc.
> >
> > It all boils down to
On Friday 21 January 2011 20:02:47 Grant Likely wrote:
> > Right, current thoughts after some IRC discussion are:
> >
> > * busybox
> > * no package manager
> > * max size of 30mb (without kernel)
> > * some further removal of packages
> >
> > I think with this in place you will get a ~30mb com
U-Boot got faster in the last cycle (v2010.12). Cache is now enabled
on arm and multiblock reads were added to the mmc driver.
On Fri, Jan 21, 2011 at 2:25 PM, Arnd Bergmann wrote:
> On Friday 21 January 2011 18:42:55 David Rusling wrote:
>> Yes, but isn't initrd slow to copy from the boot medi
On Friday 21 January 2011 18:42:55 David Rusling wrote:
> Yes, but isn't initrd slow to copy from the boot media
> (caches off, simple byte by byte copy)?
I hadn't considered this, but I guess this also depends a
lot on the boot loader that is being used. Does uboot always
run with caches disabled
On Fri, 21 Jan 2011, Pawel Moll wrote:
> VE suffers from serious problem with MMC transfers - low performance,
> errors when other IO peripherals (especially USB) are used at the
> same time etc.
>
> It all boils down to the MMC controller short FIFO and - in result -
> timing constrains. The mos
On Fri, 21 Jan 2011, Nicolas Pitre wrote:
> On Fri, 21 Jan 2011, john stultz wrote:
>
> > On Fri, 2011-01-21 at 00:36 -0800, john stultz wrote:
> > > Hey Nicolas,
> > > Over the last few days I've been playing with recent kernels on a
> > > BeagleBoard xM. So far I've gotten Linus' v2.6.37 kern
Joey,
I entered a bug for this against the omap3 kernel. USB mouse and
keyboard work on beagle which uses the same kernel.
https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/706033
John
On Fri, Jan 21, 2011 at 10:59 AM, Joey Stanford
wrote:
> fwiw, I'm using the headless image on
On Fri, Jan 21, 2011 at 8:50 AM, Jamie Bennett wrote:
> On 21 Jan 2011, at 15:42, Loïc Minier wrote:
>
>> On Fri, Jan 21, 2011, Jamie Bennett wrote:
>>> Currently we are reassessing whether or not the Headless image meets
>>> the requirements for a small, fast, useable image for board
>>> verifica
On Fri, 21 Jan 2011, john stultz wrote:
> On Fri, 2011-01-21 at 00:36 -0800, john stultz wrote:
> > Hey Nicolas,
> > Over the last few days I've been playing with recent kernels on a
> > BeagleBoard xM. So far I've gotten Linus' v2.6.37 kernel booting, as
> > well as the android-2.6.37 git tre
> Now I'm confused again. To me, -1008 seems a lot different to -24 ?
> Do I have to get headers somewhere at linaro.org?
Nevermind, I found the package linux-headers-2.6.35-1008-linaro-omap.
(Did I warn about me being a noob?)
It still doesn't compile, there seems to be a more fundamental probl
fwiw, I'm using the headless image on my overo board and not
everything on the support board is enabled... e.g. I can't plug in a
USB keyboard or mouse (don't think it's in the kernel).
On Fri, Jan 21, 2011 at 6:22 AM, Jamie Bennett wrote:
> Hi,
>
> Currently we are reassessing whether or not the
On 01/21/2011 06:40 PM, Stehle, Vincent wrote:
2011/1/21 Jörg Hohensohn:
(pvr dkms module)
Anyway, it wants to be compiled on the target, so I tried.
The compilation under /usr/src/powervr-omap3-3.01.00.07 failed. A makefile
variable KERNELDIR did not get assigned. I still have to look at the
de
Yes, but isn't initrd slow to copy from the boot media (caches off, simple byte
by byte copy)?
Dave
On 21 Jan 2011, at 16:27, Arnd Bergmann wrote:
> On Friday 21 January 2011 16:50:37 Jamie Bennett wrote:
>>> Could we do with an initrd instead of an image? I mean, busybox +
>>> small set of t
2011/1/21 Jörg Hohensohn :
(pvr dkms module)
> Anyway, it wants to be compiled on the target, so I tried.
> The compilation under /usr/src/powervr-omap3-3.01.00.07 failed. A makefile
> variable KERNELDIR did not get assigned. I still have to look at the
> details, but I found hard-coded paths to so
On 01/20/2011 08:36 PM, Jesse Barker wrote:
> For your OMAP3 board, you are probably better off sticking with the
ubuntu packages
> (you'll need to add multiverse in order to find the various
'*-sgx-omap3' packages)
> as that will get you up and running fastest.
Thanks for that hint, I didn't
A word of comment...
At least some of the Linaro file system images are running irqbalance
daemon, which will most likely play with MMC and USB interrupts
affiliation in runtime. To prevent it from doing so,
/etc/default/irqbalance should contain this line:
export IRQBALANCE_BANNED_INTERRUPT
On Friday 21 January 2011 16:50:37 Jamie Bennett wrote:
> > Could we do with an initrd instead of an image? I mean, busybox +
> > small set of tools is probably enough for validation, and will be quite
> > small.
> >
> > There is inherent bloat as soon as we add a package manager in the mix
>
>
On Fri, Jan 21, 2011 at 3:42 PM, Loïc Minier wrote:
> On Fri, Jan 21, 2011, Jamie Bennett wrote:
>> Currently we are reassessing whether or not the Headless image meets
>> the requirements for a small, fast, useable image for board
>> verification. Just for information the current stats as of 2011
On 21 Jan 2011, at 15:42, Loïc Minier wrote:
> On Fri, Jan 21, 2011, Jamie Bennett wrote:
>> Currently we are reassessing whether or not the Headless image meets
>> the requirements for a small, fast, useable image for board
>> verification. Just for information the current stats as of 2011-01-21
Dnia wtorek, 18 stycznia 2011 o 18:26:17 Marcin Juszkiewicz napisał(a):
> Dnia wtorek, 18 stycznia 2011 o 12:36:33 Marcin Juszkiewicz napisał(a):
> > I would like to announce new Linaro PPA available for all users of Ubuntu
> > 10.04 Lucid and 10.10 Maverick releases:
> >
> > https://launchpad.ne
On Fri, Jan 21, 2011, Jamie Bennett wrote:
> Currently we are reassessing whether or not the Headless image meets
> the requirements for a small, fast, useable image for board
> verification. Just for information the current stats as of 2011-01-21
> are:
>
> * Download Size: 64M
> * Download siz
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro Developer Platforms Weekly Status meeting held on January 19th
in #linaro-meeting on irc.freenode.net at 15:00 UTC.
https://wiki.linaro.org/Platform/Foundations/2011-01-19
Regards,
Tom (tgall_foo)
Developer Platforms Tea
the above sizes are with or without kernel?
Without.
Anyone knows how
compression of cramfs compares to tar.gz? e.g. can we compare those
sizes directly to our gzipped tarballs?
I did a quick exercise of uncramfs-ing and tar-gz-ipping the v7
versions back. Results:
49164288 filesystem_bin
Hello.
Pawel Moll wrote:
VE suffers from serious problem with MMC transfers - low performance,
errors when other IO peripherals (especially USB) are used at the
same time etc.
It all boils down to the MMC controller short FIFO and - in result -
timing constrains. The most problematic case -
On Fri, Jan 21, 2011 at 2:33 PM, Pawel Moll wrote:
>> * Download Size: 64M
>> * Download size with OMAP3 hwpack: 100M
>> The current thoughts are to cut this image down as much as possible
>> whilst still retaining the ability to boot to a command prompt. The
>> new image would be a 'nano' image
VE suffers from serious problem with MMC transfers - low performance,
errors when other IO peripherals (especially USB) are used at the
same time etc.
It all boils down to the MMC controller short FIFO and - in result -
timing constrains. The most problematic case - USB driver hogging
CPU and MMC
On Fri, Jan 21, 2011, Ramana Radhakrishnan wrote:
> I'm curious to hear what packaging methods would be used for things like
> the toolchain which have consumers beyond ubuntu. Are we saying this
> will only be Ubuntu packages or is there consensus around providing
> static tarballs ?
For output
* Download Size: 64M
* Download size with OMAP3 hwpack: 100M
The current thoughts are to cut this image down as much as possible
whilst still retaining the ability to boot to a command prompt. The
new image would be a 'nano' image and would be useful for verifying
that the hardware boots.
Yes,
Back in November I had prototyped something like this and even called
it nano. Here's the post I made to the list about it and using then
current hwpack + then current headless how I was able to chop things
down considerably.
http://lists.linaro.org/pipermail/linaro-dev/2010-November/001439.html
On 21 January 2011 13:22, Ramana Radhakrishnan
wrote:
> I'm curious to hear what packaging methods would be used for things like
> the toolchain which have consumers beyond ubuntu. Are we saying this
> will only be Ubuntu packages or is there consensus around providing
> static tarballs ?
>
> I as
> Agreed. I'd like an easy way of getting pre-built binaries of all the
> stable enough Linaro outputs. On the toolchain side this would
> include the latest monthly releases of Linaro GCC, GDB, and QEMU in
> native and cross versions as appropriate. A single PPA for the whole
> of Linaro would
Hi,
Currently we are reassessing whether or not the Headless image meets
the requirements for a console-only developer focused image usable for
kernel, boot loader, power management and other types of non-gui
development. Just for information the current stats as of 2011-01-21
are:
* Download
Hi,
Currently we are reassessing whether or not the Headless image meets
the requirements for a small, fast, useable image for board
verification. Just for information the current stats as of 2011-01-21
are:
* Download Size: 64M
* Download size with OMAP3 hwpack: 100M
* Package count: 260
The
On 21 January 2011 13:08, Loïc Minier wrote:
> apt-get install btrfs-tools?
I didn't consider that :) I am now feel motivated to fix a network
connection on my board too.
>
> It seems they built for armel:
> https://launchpad.net/ubuntu/+source/btrfs-tools/0.19+20100601-3ubuntu1/+buildjob/2171
On Fri, Jan 21, 2011, Per Förlin wrote:
> I am using the linaro-m-headless-rootfs and tools for btrfs are missing.
> I want to put btrfs on the onboard MMC and therefore I would like to
> run btrfs-tools on target.
>
> Does any one have arm version of the btrfs-tools?
apt-get install btrfs-tools
Hi,
I am using the linaro-m-headless-rootfs and tools for btrfs are missing.
I want to put btrfs on the onboard MMC and therefore I would like to
run btrfs-tools on target.
Does any one have arm version of the btrfs-tools?
BR
Per
___
linaro-dev mailin
I suppose attached patch from Paul should fix this issue.
regards
Vishwa
On Fri, Jan 21, 2011 at 2:41 PM, john stultz wrote:
> On Fri, 2011-01-21 at 00:36 -0800, john stultz wrote:
>> Hey Nicolas,
>> Over the last few days I've been playing with recent kernels on a
>> BeagleBoard xM. So fa
On Thu, Jan 20, 2011, Steve Langasek wrote:
> - the overlay ppa is the only one that should be enabled for Linaro release
>images
[...]
I like the clear limits you're setting to the overlay PPA (rejecting
any other concurrent overlays)
> As for the 'tools' ppa, I had envisioned this as the
On Fri, 2011-01-21 at 00:36 -0800, john stultz wrote:
> Hey Nicolas,
> Over the last few days I've been playing with recent kernels on a
> BeagleBoard xM. So far I've gotten Linus' v2.6.37 kernel booting, as
> well as the android-2.6.37 git tree booting as well. However, when I try
> to boot
Hey Nicolas,
Over the last few days I've been playing with recent kernels on a
BeagleBoard xM. So far I've gotten Linus' v2.6.37 kernel booting, as
well as the android-2.6.37 git tree booting as well. However, when I try
to boot the latest linaro 2.6.37 git tree, I just get:
Starting kerne
43 matches
Mail list logo
