Antonio Terceiro antonio.terceiro@linaro.org writes:
On Mon, May 06, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
Antonio Terceiro antonio.terceiro@linaro.org writes:
*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.
I think I was not clear enough in my post.
Not your fault, I'm rather confused about LAVA terminology myself, so may be using the wrong terms.
LAVA has a set of device type implementations (i.e. Python classes) to handle the interactions with different devices/setups:
lava_dispatcher/device/fastboot.py lava_dispatcher/device/fastmodel.py lava_dispatcher/device/qemu.py lava_dispatcher/device/sdmux.py
lava_dispatcher/device/master.py lava_dispatcher/device/uefi.py lava_dispatcher/device/vexpress.py lava_dispatcher/device/highbank.py
When you create a device-type configuration file, you specify which one of those implementations you want to use, like this:
$ grep client_type lava_dispatcher/default-config/lava-dispatcher/device-types/nexus.conf client_type = fastboot
The default client_type is `master`, which is the right choice for most setups that do use a master image. Since your device-type conf file does not say anything, it is using `master`, which is not what you want. With a proper device type implementation, all the problems you faced will go away.
[lightbulb appears over head]
Aha, that definitely sounds like what I need.
I think what's needed is a u-boot device type (or whatever its called). The setup I'm aiming for is where u-boot boots directly into a test kernel, and is able to run tests via lava_test_shell. (NOTE: lava_test_shell also wants to reboot again after loading its tests. lava_test_shell itself has lots of other assumptions/dependencies about the master image, but that's a different thread.)
(the naming is a little confusing; when we say "device type" we might mean the Python implementation or LAVA configuration items in device-types/foo.conf. The fact it's called client_type in the configuration file does not help)
Yes, the naming is very confusing, and the documentation (or lack thereof) does not help either. Also, the LAVA interface itself uses device_type pretty consistently to refer to LAVA configuration items in the device-types/ dir, so confusion abounds.
For example the qemu¹, fastmodel, and fastboot types, for example, do not assume a master image, and a new implementation for this use case would look a lot like them.
¹ 61 LOC
Cool
It would be great if someone in the LAVA team could work up a simple u-boot type. I'm supposed to be working on the kernel, so I don't have the time to spend learning LAVA internals. What would take me several days to understand and write would probably take one of you guys a couple hours.
If someone wants to tackle that, I'll be glad to do some experiments with it to see if it can be useful.
Thanks,
Kevin