Hi Nico,
On Wed, Jan 19, 2011 at 2:39 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
OK. Will the debugfs format be identical and will this work identically
from a user space point of view once this is based on top of the common
clock API? If yes then I'm happy to merge it into the Linaro
change log:
Add more description in commit.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, Jan 19, 2011 at 3:02 AM, Loïc Minier loic.min...@linaro.org wrote:
Hey there
As a result of a series of bugs around linaro-image-tools and daily
images, it seemed a sensible approach to solve this class of issues
would be to move more data into hardware packs rather than
On Wed, Jan 19, 2011 at 2:02 AM, Loïc Minier loic.min...@linaro.org wrote:
Hey there
As a result of a series of bugs around linaro-image-tools and daily
images, it seemed a sensible approach to solve this class of issues
would be to move more data into hardware packs rather than
Infrastructure Team
* Period: (20110113-20110119)
*
PM: Ian Smith ian.sm...@linaro.org mailto:ian.sm...@linaro.org
*
Past reports : https://wiki.linaro.org/Platform/Infrastructure
*
Burndown information : http://status.linaro.org
http
On Wed, Jan 19, 2011, Amit Kucheria wrote:
Am I correct in my understanding then, that this will address some of
the issues I raised in
https://wiki.linaro.org/Platform/Infrastructure/Specs/TestDrive ?
Basically l-m-c won't have to be touched everytime we add new board
support?
Yes, I think
On Wed, 2011-01-19 at 02:02 +0100, Loïc Minier wrote:
Hey there
As a result of a series of bugs around linaro-image-tools and daily
images, it seemed a sensible approach to solve this class of issues
would be to move more data into hardware packs rather than hardcoding
stuff in
On Wed, Jan 19, 2011 at 1:42 PM, Loïc Minier loic.min...@linaro.org wrote:
On Wed, Jan 19, 2011, Amit Kucheria wrote:
Am I correct in my understanding then, that this will address some of
the issues I raised in
https://wiki.linaro.org/Platform/Infrastructure/Specs/TestDrive ?
Basically l-m-c
Hey
Based on an idea by Ulrich Weigand, I've uploaded a new gdb to natty
today which adds a gdb-multiarch binary package. It's about 19 MB and
once you install it, you will get a new /usr/bin/gdb-multiarch which
can debug any target that gdb knows about, including ARM!
So you could
On Wed, 2011-01-19 at 12:39 +0100, Alexander Sack wrote:
On Wed, Jan 19, 2011 at 2:02 AM, Loïc Minier loic.min...@linaro.org wrote:
Hey there
As a result of a series of bugs around linaro-image-tools and daily
images, it seemed a sensible approach to solve this class of issues
On Wed, Jan 19, 2011, Guilherme Salgado wrote:
This looks good to me. The only thing I can think of right now is to
also add the board name to the hwpack meta-data and consider dropping
the --dev option (making it optional, in fact, so that it keeps working
with hwpacks in the current format)
On Wed, 2011-01-19 at 13:54 +0100, Loïc Minier wrote:
On Wed, Jan 19, 2011, Guilherme Salgado wrote:
This looks good to me. The only thing I can think of right now is to
also add the board name to the hwpack meta-data and consider dropping
the --dev option (making it optional, in fact, so
On Wed, Jan 19, 2011, Guilherme Salgado wrote:
Right now I don't have a use-case for it, but at the same time that I
want to make the --dev argument not needed (after all, the user already
specifies the hwpack for a specific board, so there's no point in
forcing them to specify that yet
On Wed, 19 Jan 2011 02:02:57 +0100, Loïc Minier loic.min...@linaro.org wrote:
Hey there
As a result of a series of bugs around linaro-image-tools and daily
images, it seemed a sensible approach to solve this class of issues
would be to move more data into hardware packs rather
On Wed, Jan 19, 2011, James Westby wrote:
Would in general be nice to deal with other image types like Android
and ChromeOS and avoid .debs unless targetting Ubuntu images.
I think this is the wrong aim to be putting in the document. I think
that the aim should be to be able to produce
Hi,
I'm have trouble receiving a video stream on the Freescale i.MX51
processor. I've tried everything I could think, so I'm trying my luck
here.
I'm using a 2.6.31 kernel with some modifications: the camera capture
driver [1] and the IPU (Image Processing Unit) driver [2] from the
Freescale BSP
Hi,
The weekly Linaro Release Meeting will be held at 17:00 UTC tomorrow
(Thursday). Please note the change of day which is due to a resolution
in meeting conflicts meaning the release meeting can return to its
normal slot. The agenda for the meeting can be found at:
Hello Everyone,
The action packed minutes of the weekly call can be found at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-01-19
Attendees: Full house!
Regards,
Amit
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
Hi all,
I had a go at hacking up a tool to copy sparse images to cards less
wastefully (and hopefully faster) by only coping to the important
data: See the src/fibcp.c here:
git://git.linaro.org/people/dmart/tools.git
It's used like this:
# fibcp image.bin /dev/sdcard
There are some caveats,
On Wednesday 19 January 2011, Nicolas Pitre wrote:
On Wed, 19 Jan 2011, Loïc Minier wrote:
On Wed, Jan 19, 2011, James Westby wrote:
fdt
What would we do with this if we found it in a hwpack?
I don't know; I need more handson experience with DT to tell. It might
be that
On Wed, Jan 19, 2011, Arnd Bergmann wrote:
More importantly, you might want to update the fdt files on a different
cycle than the kernel. If you have a new slightly different configuration
in a new machine you want to support, it may be easier to add a new file
somewhere than doing a respin of
On Wed, 19 Jan 2011 15:58:34 +0100, Loïc Minier loic.min...@linaro.org wrote:
Hmm maybe the wording was poor, but it's definitely the intent that the
hwpacks be kept as portable across image types as possible.
Right, I agree with the goal. My comment is just the wording, talk about
the aim,
Hi,
On Wed, Jan 19, 2011 at 3:57 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 19 January 2011, Dave Martin wrote:
It works well enough that e2fsck passes after a writing an image to a
card which was previously full of random data.
Anyway, it's there if anyone wants to play with it --
Okay we can make an SD card that will force a U-Boot update and power
down easily..
--
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
On Wed, Jan 19, 2011 at 4:37 AM, Per Forlin per.for...@linaro.org wrote:
Hi Matt,
On 18 January 2011 15:03, Matt Sealey
On Wed, Jan 19, 2011, James Westby wrote:
Right, but what would they do? That's my point.
If you really want to push Andoid in to v2 then we can write code to
identify/specify image type, then defer Android/linux_image combination
with a specific error message.
The point of a format
On Wed, Jan 19, 2011, Matt Sealey wrote:
Okay we can make an SD card that will force a U-Boot update and power
down easily..
This would be awesome!
Speaking for other Linaro needs, it would be nice if we could reproduce
this build ourselves as to allow us to create special purpose u-boots.
On Wednesday 19 January 2011, Dave Martin wrote:
Hi,
On Wed, Jan 19, 2011 at 3:57 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 19 January 2011, Dave Martin wrote:
It works well enough that e2fsck passes after a writing an image to a
card which was previously full of random data.
On Wed, 19 Jan 2011, yong.s...@linaro.org wrote:
From: Yong Shen yong.s...@linaro.org
Expose clock debug information to debugfs, which makes it easier for clock
system debug by using tools like powerdebug developed by Linaro power
management group.
For long term, this can go into common
On Wed, 2011-01-19 at 13:22 +0200, Amit Kucheria wrote:
On Wed, Jan 19, 2011 at 3:02 AM, Loïc Minier loic.min...@linaro.org wrote:
Hey there
As a result of a series of bugs around linaro-image-tools and daily
images, it seemed a sensible approach to solve this class of issues
On Wed, 19 Jan 2011 15:45:54 -0700, John Rigby john.ri...@linaro.org wrote:
Sorry for entering late here. Here are my questions:
How does l-m-c know about the boot partition convention? Is the fact
that omap wants a dos partition with some files on it but i.MX just
needs the raw bits at a
On Wed, 19 Jan 2011 17:58:04 +0100, Loïc Minier loic.min...@linaro.org wrote:
That's exactly my point: have the next version of the code try to do
the right thing. Maybe I actually have broken expectations: I expect
l-i-t would reject hwpacks with unknown fields. That's the failure
I'm
Hi ,
Do we have ALIP project files (git://linux.onarm.com/git/alip-project.git)
replicated on linaro site ? Would like to know the new git address for ALIP
project
-shankar
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
32 matches
Mail list logo
