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
http://lists.linaro.org
FYI:
I've just created a page describing how to get a Linaro image running on
the Overo Gumstix board:
https://wiki.linaro.org/Boards/Overo/Setup
-andy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/l
On Wed, 2011-01-19 at 10:17 -0600, James Westby wrote:
> > > I don't think there's any point in ignoring this now, and then doing
> > > something with it later. It should have a hwpack format bump so that
> > > users can be told that they need a newer l-m-c, otherwise when we first
> > > release A
On Wed, 2011-01-19 at 15:02 -0600, James Westby wrote:
> An illustration of what I mean: if we add linux_image and ignore it, and
> then use it within Android hwpacks, someone with the old code will try
> and use one of those new hwpacks, and get an unbootable Android
> image. When that happens so
On Wed, 19 Jan 2011 17:58:04 +0100, Loïc Minier 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 trying to avoid if w
On Wed, 19 Jan 2011 15:45:54 -0700, John Rigby 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 fixed location on
On Wed, 2011-01-19 at 13:22 +0200, Amit Kucheria wrote:
> On Wed, Jan 19, 2011 at 3:02 AM, 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
On Wed, 19 Jan 2011, yong.s...@linaro.org wrote:
> From: Yong Shen
>
> 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 clock framework,
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 fixed location on the card embedded in l-m-c?
If a new platform pops up with a com
Hey
I've just uploaded linaro-image-tools 0.4(.1) to natty; thanks to the
hard work of Michael Hudson, Guilherme Salgado, James Westby, Martin
Ohlsson and many others, we have an awesomely nicer tool to write our
Linaro images.
For developers: please note that the branch location jus
On Wednesday 19 January 2011, Dave Martin wrote:
> Hi,
>
> On Wed, Jan 19, 2011 at 3:57 PM, Arnd Bergmann 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, 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 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
Okay we can make an SD card that will force a U-Boot update and power
down easily..
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Wed, Jan 19, 2011 at 4:37 AM, Per Forlin wrote:
> Hi Matt,
>
> On 18 January 2011 15:03, Matt Sealey wrote:
>>
>> IN THEORY, the system should
Hi,
On Wed, Jan 19, 2011 at 3:57 PM, Arnd Bergmann 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 -- comme
On Wed, 19 Jan 2011 15:58:34 +0100, Loïc Minier 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, not about "avoiding .d
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 -- comments welcome.
* You write with a block size of just 4kb here, whi
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
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 m
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/
There are some caveats, most n
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 we don't need this this cycle because the DT will b
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
http:
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:
https://wiki.linaro.org/Relea
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
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 produ
On Wed, 19 Jan 2011 02:02:57 +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
> st
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 aga
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
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 forma
On Wed, 2011-01-19 at 12:39 +0100, Alexander Sack wrote:
> On Wed, Jan 19, 2011 at 2:02 AM, 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
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 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 lin
On Wed, Jan 19, 2011 at 1:42 PM, Loïc Minier 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 won't have to
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 t
Infrastructure Team
* Period: (20110113-20110119)
*
PM: Ian Smith mailto:ian.sm...@linaro.org>>
*
Past reports : https://wiki.linaro.org/Platform/Infrastructure
*
Burndown information : http://status.linaro.org
<http://status.linaro.org/&g
On Wed, Jan 19, 2011 at 2:02 AM, 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 i
Dnia środa, 19 stycznia 2011 o 12:20:02 Michael Opdenacker napisał(a):
> We now recommend these packages in my company's embedded Linux training
> materials. See p. 25 of http://free-electrons.com/doc/toolchains.pdf
> (and correct me if I wrote anything wrong!).
Since maverick Ubuntu users do not
On Wed, Jan 19, 2011 at 3:02 AM, 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 i
Hi Marcin,
On 01/18/2011 06:26 PM, Marcin Juszkiewicz wrote:
> 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.net/~linaro-mainta
Hi Matt,
On 18 January 2011 15:03, Matt Sealey wrote:
>
> IN THEORY, the system should flash it and then power off. You'll see
> the caps lock led blink 3 times then it'll shut down. At this point
> take the SD out... flip the DIPs back, et voila. However if the system
> is constantly rebooting a
From: Yong Shen
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 clock framework, but so far it depends
on the process of common clk API develop
change log:
Add more description in commit.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi Nico,
On Wed, Jan 19, 2011 at 2:39 AM, Nicolas Pitre 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 kernel
> tree.
Yes, th
43 matches
Mail list logo
