[Bug 680650] Re: Track available RAM in hardware packs

2013-08-23 Thread Alan Bennett
Due to the age of this issue, we are acknowledging that this issue will likely not be fixed, is no longer applicable, or was already fixed by an indirect change. If this issue is still important, please add details and reopen the issue. ** Changed in: linaro-image-tools Status: New => Won

[Bug 680650] Re: Track available RAM in hardware packs

2011-03-25 Thread Alexander Sack
So in general I don't think its a big problem to rely on our user audience making a wise decision about selecting swap or not. If we do something we should only warn about a potential unwise decision and not make automatic decisions on swap etc. I guess there are various ways this could be done a

[Bug 680650] Re: Track available RAM in hardware packs

2011-02-25 Thread Loïc Minier
Removing milestone as this bug currently doesn't have a clear path forward ** Changed in: linaro-image-tools Milestone: 0.5.0 => None -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/680650 Title:

Re: [Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread Steve Langasek
On Tue, Feb 01, 2011 at 05:06:36PM -, James Westby wrote: > > > What do we do when a hwpack is shared between two boards with differing > > > amounts of RAM? > > Use the more conservative figure for available RAM and create larger swap by > > default? > Why not create some amount of swap by d

Re: [Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread James Westby
> > Does this really belong in the hwpack? > > Where else could we put it? Nowhere? I'm really just exploring the requirements here. > > What do we do when a hwpack is shared between two boards with differing > > amounts of RAM? > > Use the more conservative figure for available RAM and create

Re: [Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread Steve Langasek
On Tue, Feb 01, 2011 at 02:39:17PM -, James Westby wrote: > On Tue, 01 Feb 2011 14:01:05 -, Loïc Minier wrote: > > Jamie will amend the documentation to mention that --swap_size should > > definitely be passed for some images; I'm keeping a bug task open for > > the hardware pack v2 ram_si

[Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread Loïc Minier
Peter gave the example of beagle vs beagle XM as boards supported with same u-boot etc. but differing amounts of RAM I can also think that some boards have variable amounts of RAM (e.g. DDR) so doesn't sound like a good idea to handle this in hwpack v2 indeed. -- You received this bug notificati

[Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread Loïc Minier
It hadn't realized that hwpacks could be shared between boards; this doesn't seem like a good idea to me as it means we need multiple version of the metadata: which fdt to use, which board name we mean, which u-boot to use etc. -- You received this bug notification because you are a member of Ubu

Re: [Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread James Westby
On Tue, 01 Feb 2011 14:01:05 -, Loïc Minier wrote: > Jamie will amend the documentation to mention that --swap_size should > definitely be passed for some images; I'm keeping a bug task open for > the hardware pack v2 ram_size implementation. Does this really belong in the hwpack? What do we

[Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread Loïc Minier
Tom, can you confirm that passing "--swap_size somethinglarge" to linaro-media-create fixes this? Also, which specific error from your dmesg was this about? there are multiple ones PS: please include all the information in the bug itself, perhaps as a dmesg attachment, rather than linking to a p

[Bug 680650] Re: Track available RAM in hardware packs

2011-02-01 Thread Loïc Minier
Jamie will amend the documentation to mention that --swap_size should definitely be passed for some images; I'm keeping a bug task open for the hardware pack v2 ram_size implementation. Ideally, we'd also have a better rootfs format to carry meta information such as required RAM size, but we don't