This thread received relatively negative feedback on the use of hwpacks
along Android/ChromeOS images. I think we should defer this part, at
least we have more experience with said images.
I do agree with the overall approach of doing things in the upsteam
way. I'm less clear on how end-use
On Wed, Jan 19, 2011, John Rigby wrote:
> How does l-m-c know about the boot partition convention?
I've just added to the wiki page; this came up yesterday on IRC when we
started taking imx51 into account.
We would have a partition_layout field which commands which partition
layout type we wa
On 20 January 2011 05:15, Scott Bambrough wrote:
> 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,
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
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
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, 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 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
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
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
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
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
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
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
26 matches
Mail list logo
