Antonio Terceiro antonio.terceiro@linaro.org writes:
On Mon, May 06, 2013 at 10:43:12AM +1200, Michael Hudson-Doyle wrote:
Kevin Hilman khilman@linaro.org writes:
Michael Hudson-Doyle michael.hudson@linaro.org writes:
Kevin Hilman khilman@linaro.org writes:
Hi LAVA folks,
I'm working on using LAVA to boot boards in my own board farm, and for starters, am trying to use a job without a 'deploy' step (so I can use the existing on-board u-boot, and control it via boot_cmds.)
Currently, the dispatcher assumes that a 'deploy' step has happened before a 'boot_linaro_image' step, which is not needed for my case, so here's a patch to set some defaults so a deploy step is not needed:
FWIW, there is a dummy_deploy action for this use case:
"actions": [ { "command": "dummy_deploy", "parameters": { "type": "ubuntu" } }, { "command": "boot_linaro_image" } ]
Thanks for the pointer, but this doesn't work either. While dummy_deploy may be dumb, it's not dumb enough. It still wants to (re)boot into a master image (which I don't wan't.)
Ah right. I don't really see any reason for that, sounds like something that should be fixed!
Agreed.
*But* if the setup does not use a master image, the `master` device type should be the coice, since it was entirely designed with the assumption that there *is* a master image.
Yes, this assumption is a major problem for more "direct" use of LAVA for regular kernel development.
After a almost 2 weeks of tinkering with LAVA (including making piles of hacks and changes to the code), I've come to the conclusion that there are fundamental design decision in LAVA that make it very difficult to use for kernel development. Unfortunately, I don't have any more time to spare to make it work.
We should probably write a new device type for this use case.
The device type is only part of the problem. I've written a custom device type for treating u-boot as a "master image" and using boot_cmds to directly boot the test kernel. But there are still several other places that assume a master image.
Kevin