On Mon, Feb 13, 2012 at 11:43 PM, Paul Larson paul.larson@linaro.org wrote:
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.
Sure, if we do then this is good. But this would be solving a problem that does not exist at all with NFS based approach. We just need to figure out which tree is the tree that has our A15 kernel. We build those, stick them out as "hwpack" or whatever (it will never see l-m-c fortunately). Then LAVA gets to use it as is.
The alternative is to venture on a bootloader development quest to support booting from SD. Use QEMU (which will not work on ARMv8 unless someone fixed that already) to create a pre-installed image. Lastly LAVA would consume this image, manipulate it further (which _is_ annoying as oneiric kernel has no support for partitions on loopback devices) only to spawn fast models with a SD card image instead of unpacked root filesystem.
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 cannot judge how easy/hard this task is.
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.
I don't see the advantage of that over what we have already.
Thanks ZK