On 20 January 2011 05:15, Scott Bambrough scott.bambro...@linaro.orgwrote:
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
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
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
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
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,
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, 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
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 linaro-image-tools.
Guilherme, Steve Langasek, and Michael
20 matches
Mail list logo
