On 11 May 2018 at 23:44, Kevin Hilman khilman@baylibre.com wrote:
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.
That is a test writer decision, not an admin decision.
For example, device-A and device-B share this same device-type.
Let me stop you there. The devices are equivalent hardware but are NOT the same device-type.
https://staging.validation.linaro.org/static/docs/v2/devicetypes.html#device...
"Typically, the distinction between two device types comes down to whether the two devices can be driven in the same way at bootloader level, from initial power on."
The vendor U-Boot cannot be driven in the same way as the mainline U-Boot, therefore, a different device-type is appropriate.
Note also that, with V2, this does not have to be a different device-type in the database, it can be managed by having multiple Jinja2 device-type templates and the device dictionary extends the relevant one. (Juno does this). That then requires that device tags are used by the test writer to distinguish between the devices and therefore requires that the test job submission matches the relevant file types to the relevant device tags.
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".
No. It needs the file supplied to LAVA to be a uImage.
The correct solution here is to have multiple device-types. The primary bootloader has different functional capabilities - that is one of the most common reasons to create a different device type.
But the job submitter is not (and should not be) aware which of the devices will be chosen,
The test job submitter is the only person who can be aware of what files are to be delivered to LAVA. The test job submitter must therefore take into account what device-types are available. This means that the test job submitter must always be aware of the capabilities of the device-type (or the specific device tags).
Otherwise LAVA gets in the way of use cases where the test writer explicitly requires to test that the relevant bootloader correctly fails to handle files it genuinely cannot use. This is a valid use case for LAVA. Quite often, a failed test job is a valid result.
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.)
However, the basic premise is still as flawed. The device-type is the wrong place to do this.
It is the sole responsibility of the test writer to correctly describe the files to be used in the test job in a deterministic way such that the dispatcher does not do the old V1 style magic conversions which are known to be unreliable, non-portable and buggy.
Test job submissions can easily use templating to sort out the correct test job submission elements, e.g. when processing the step after the build but before submission to LAVA where all of this information is available.
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.
There is no goal for LAVA making that abstraction. That was one of the horrendous mistakes made in V1.
LAVA is not about hiding the bootloader functionality from the test job writer, LAVA tries to give the test job writer all the tools required to fully utilise the bootloader and that requires the test job writer knowing how to use the bootloader.
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." ?
This would not be suitable for use upstream as it breaks the review criteria. It is putting the logic in the wrong place.
LAVA does not do magic file conversion in the codebase - there is support for that using LXC. The exception is the work required to apply the Lava Test Definition scripts.
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.
The test job submission as received by lava_dispatcher must be valid - that means that the URLs provide the correct type of files. If the dispatcher has to do work, that work must be prescribed in the test job submission - this is a key part of the design of LAVA to keep the dispatcher dumb. lava-run does exactly and precisely only what it is told to do by lava-master. It doesn't make any decisions or any assumptions not prescribed in the test job submission or device configuration.
This level of abstraction is a return to the days of embedding magical logic inside lava-dispatcher and breaks the model for how LAVA test jobs can be reproduced outside LAVA.
If the files downloaded are not suitable for direct usage on the device, then the supported method is to use LXC to do the conversion work using a portable script that can be run by a developer trying to reproduce a test job on a local device, outside LAVA.
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/prepare.py#L119 _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users