+1 on Michael's suggestion to use dummy_deploy

I've had some conversions with Kevin about his use requirements for LAVA, and here is a summary:

* For kernel testing, the kernel binary + ramdisk is provided over tftp. I think he has figured out how to override the boot_cmds so this is not an issue. * Would like to utilize lava-test-shell however lava-test-shell makes assumptions about the rootfs. His idea is provide all the lava-test-shell support scripts in the ramdisk. All his existing tests are already included on this ramdisk.

Perhaps we can create another "type" for deployment data called "vanilla"

"actions": [ { "command": "dummy_deploy", "parameters": { "type": "vanilla" } }, { "command": "boot_linaro_image" } ]

Target.vanilla_deployment_data['distro'] = 'vanilla' Target.vanilla_deployment_data['lava_test_sh_cmd'] = '/bin/bash' Target.vanilla_deployment_data['lava_test_dir'] = '???' Target.vanilla_deployment_data['lava_test_results_part_attr'] = '???'

This "vanilla" target could carry the assumption that the lava-test-shell support scripts are already on the target...somewhere.

On 2 May 2013 15:29, Michael Hudson-Doyle michael.hudson@linaro.org wrote:

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" } ]

Cheers, mwh

---

linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation

Antonio Terceiro antonio.terceiro@linaro.org writes:

On Thu, May 02, 2013 at 03:54:25PM -0700, Tyler Baker wrote:

...

+1 on Michael's suggestion to use dummy_deploy

I've had some conversions with Kevin about his use requirements for LAVA, and here is a summary:

• For kernel testing, the kernel binary + ramdisk is provided over tftp. I

think he has figured out how to override the boot_cmds so this is not an issue.

• Would like to utilize lava-test-shell however lava-test-shell makes

assumptions about the rootfs. His idea is provide all the lava-test-shell support scripts in the ramdisk. All his existing tests are already included on this ramdisk.

Perhaps we can create another "type" for deployment data called "vanilla"

"actions": [ { "command": "dummy_deploy", "parameters": { "type": "vanilla" } }, { "command": "boot_linaro_image" } ]

Target.vanilla_deployment_data['distro'] = 'vanilla' Target.vanilla_deployment_data['lava_test_sh_cmd'] = '/bin/bash' Target.vanilla_deployment_data['lava_test_dir'] = '???' Target.vanilla_deployment_data['lava_test_results_part_attr'] = '???'

This "vanilla" target could carry the assumption that the lava-test-shell support scripts are already on the target...somewhere.

If the ramdisk is passed explicitly to LAVA,

It's not.

It might be an initramfs (built into the kernel), or it might be a rootfs on MMC that already contains a bunch of tests.

Here, we should have the option of avoiding the whole tar-it-up, download, reboot cycle that lava-test-shell currently does.

then we could make a copy of it, them let lava-test-shell add its stuff inside the copy, and use that instead of the original ramdisk to boot the kernel.

I'd rather see a skeleton package for the lava-test-shell stuff needed on the target so it can be pre-installed.

Kevin

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

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