On Mon, Feb 13, 2012 at 2:32 PM, Zygmunt Krynicki <zygmunt.krynicki@linaro.org> wrote:
On Mon, Feb 13, 2012 at 11:13 PM, Paul Larson <paul.larson@linaro.org> wrote:
> But what you said earlier was that there are still a lot of complications
> around the nfs booting, especially with specifying where to boot from.

This is all fixed since we can manipulate kernel bootcmd arguments. We
just say "root=/dev/nfs nfsroot=ip:/path" while starting the model
(with a pre-built kernel)


 I
> suspect nfs is not going to be a viable option at all for things like
> android.  So what about revisiting why we cant use a real image before we
> make this more difficult than it really needs to be? I think the main thing
> was the image size, but since we've started looking at our main use cases
> for fast models, what stands out is that we really could cover our testing
> in nano and android - which should both fit fine in < 2GB.

We don't have any boot loaders that work from SD. You can still keep
the rootfs if you really want to but I don't see how that is more
complicated than NFS setup (which we already have).

I think you misunderstood what I'm getting at.  What I'm suggesting is that there should just be a proper hwpack for vexpress-a7/15+fastmodel.  This wouldn't have to be supported forever, just until we have real hardware that can be used.  My understanding from the discussion before is that this would be possible, but might require some modifications to the bootloader.  I suspect this modification would be needed for the forthcoming android image as well though.  Once we had this hwpack, it could be used to create a regular sd image that can be booted in fast models, with the restriction that it cannot be > 2GB.  nano and android should both fit well within that constraint though, and would be adequate for the testing that they want to do in fast models by way of lava.

The benefit here, is that we don't have to go through all of this again to cope with android in a few {days, weeks, months?} when we have something for android.

If ARM can fix the 2GB limit, then what that means is *if* we someday need to test using a larger image, we can. But for now, it doesn't seem to be critical.  I did mention this to Roger at the connect, but I'll also pursue this further with ARM just in case.

-Paul Larson