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.  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.

Thanks,
Paul

On Feb 13, 2012 4:03 PM, "Zygmunt Krynicki" <zygmunt.krynicki@linaro.org> wrote:
On Mon, Feb 13, 2012 at 9:54 PM, Paul Larson <paul.larson@linaro.org> wrote:
> Hi, I wanted to sync up on where things are with this, and as I understand,
> there's some confusion still about how we should get the available kernel
> and/or images for testing fast models.
>
> First off, it seems there is no way to just take a kernel .axf as we thought
> because the boot args are wrapped into it as well.  Is there really no way
> to inject that stuff after build time?

As explained in my other email this is now handled by
linux-system-semi.axf which is a small boot loader for the real
kernel.

> Is it worth revisiting whether we should have proper hwpacks for fast
> models?  I know there's the 2G max sd size issue with that, but if that's
> something arm can fix, or if we have another way around it, would that help?

My current desire is to implement NFS support. We can extend that to
NBD support if there is interest in such features.
As for fixing SD card limit, I don't know how that works. Perhaps
that's a question for ARM folks.

> Finally, I feel like we've chased a pretty messy route to get fast models
> supported here, which will ultimately break completely when we try to get
> android running also.  Please correct me if I'm wrong here, but it seems the
> "recommended" approach is currently:
> lava takes as input: git tree for the kernel we want to build, defconfig to
> use, and rootfs tarball
> lava builds the kernel (lava doesn't do this currently, complicating things
> for us quite a bit - would be better if this step could be done externally,
> like in jenkins where we do the kernel ci builds)
> lava pushes the build axf to another system where we have the fast models
> software installed, provisions the rootfs for booting over nfs
> lava boots the system under fast models on this other machine, runs tests,
> gathers results, etc
>
> Is that pretty close Zygmunt? Is there something more straightforward and
> less fragile that we can do here?

That's pretty much it. We don't need to build the kernel assuming
we're getting a pre-build kernel from somewhere with all the modules
so that we can prepare a working rootfs.

ZK
> Thanks,
> Paul Larson