Antonio Terceiro <[email protected]> writes:

> On Mon, May 06, 2013 at 10:43:12AM +1200, Michael Hudson-Doyle wrote:
>> Kevin Hilman <[email protected]> writes:
>> 
>> > Michael Hudson-Doyle <[email protected]> writes:
>> >
>> >> Kevin Hilman <[email protected]> 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



_______________________________________________
linaro-validation mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-validation

Reply via email to