I'd like a single device-type to list load addrs for booti, bootz, and bootm so it can support all three modes. That seems ok.
Next, I'd like the device-dict (not the job parameters) to be able to decide which of those to use.
For example, device-A and device-B share this same device-type. device-A runs mainline uboot and can use booti, but device-B runs a vendor uboot, which doesn't support booti, so it needs LAVA to convert the kernel "image" to a "uimage". But the job submitter is not (and should not be) aware which of the devices will be chosen, so the job submitter always submits a job with "kernel_type: image" (Yes, this is similar to the thread started by Corentin[1], but I'm trying to rephrase.)
So, device-B needs to put the text_offset in its dict, possibly override some other vars for the vendor uboot (e.g. bootloader_prompt), and that all works swimmingly.
However, the problem is that the decision to convert to uimage is made based on job paramaters (e.g. kernel_type == "uimage'[2]). But, that implies that the job *sender* needs to know whether the device to be selected supports booti or bootm, and that defeats the whole goal of LAVA hiding that. The job should just pass in an kernel with "type: image" and the device-dict is the one that should decide whether to convert to a uimage.
IOW, is there a way for the device-dict to say "I know I recevied an image of kernel_type=image, but please convert to kernel_type=uimage." ?
From what I can tell by checking the code[2], if kernel_type = "image"
and "booti" is in device_params (and it always will be because it's set in the device-type), then a uimage will never be created.
For this to work, the device-dict for device-B has to *remove* the booti_*_addr set by the device-type. I suppose that's possible in jinja2, but that seems a bit ugly. I'm hoping there's a cleaner way for the device-dict to say "please force uimage conversion and use bootm.
Thanks,
Kevin
[1] https://lists.linaro.org/pipermail/lava-users/2018-April/000994.html [2] https://github.com/Linaro/lava/blob/master/lava_dispatcher/actions/deploy/pr...