When adding devices, there is a decision to be made about what qualifies as a device type and what does not. A different type of device can mean different things, including:
However, a slight or incremental change to hardware does not necessarily mean that the updated device is a different device type. Even if a change adds significant functionality, e.g. if USB hot-plug becomes available on revision C, that does not necessarily mean that revision C is a different device type to revision A and B.
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.
Another example to consider is DTB support. If there is more than one DTB available for a particular family of devices, this will probably lead to multiple different device types. Also consider whether all devices of the proposed device type can boot all DTBs available for that type.
Administrators are free to make their own choices about what qualifies as a device type. Some factors include:
Some devices can change bootloader type within a single job, allowing a single device-type to meet the needs of a variety of different use cases. There are issues to consider here:
Latency Changing the bootloader on every test job may have significant costs in terms of job runtime. This is particularly noticeable in the length of time required before the actual test can start. In such cases, it may be worth considering a sub-type instead.
See also
Lifetime of the device Frequently writing a new bootloader may cause problems on some devices where the bootloader may be stored on media which can only be written a limited number of times.
kvm
device type but the improved device
configuration design in V2 made this unnecessary. If the only factor
requiring two device types is LAVA support, please talk to us.Once a device type has been implemented, devices added and test jobs run, it can be awkward to change the device type. Changing the device type later will make it difficult for users to find test results across this and other devices and may cause significant issues with data consistency.
Separate device types can also complicate queries and result reporting - combining two devices which eventually end up being different device types causes issues with a loss of history when the split is finally made.
It is not a good idea to split device types arbitrarily - sooner or later there may be a requirement to look at the results of jobs across both types and having an unnecessary device type is confusing for test writers. Use a device tag to describe small differences between devices of the same device type.
See also
A balance needs to be drawn between test jobs which simply want to use a known working build of the firmware and/or bootloader and those test jobs where the latest build is relevant to the success or failure of the test itself. Different test writers may have different requirements here.
An example of sub-types could be juno-uboot
compared to juno-firmware
.
Consider the principle of test one thing at a time - let userspace test jobs
run without needing to change the bootloader and let bootloader test jobs have
the ability to update by separating the device-type into two sub-types.
Think about device integration here. You need to be able to interrupt the boot process at a level below whatever you are exposing to test writers. For example, to offer test writers the ability to modify and test the firmware, the platform must offer a way to replace the firmware in an automatable manner.
There are some considerations for the names of a device-type in LAVA.
panda
or panda-es
instead of panda1
or panda2
.The name of a device type must match an available template. On the master, device-type templates are configured using jinja2 files in the directory:
/etc/lava-server/dispatcher-config/device-types/
When creating a new device type, it is recommended to add the new template file first.
panda
and panda-es
device types are separate in the Cambridge
LAVA lab. When originally introduced, there was an expectation that the
hardware differences between the devices would be relevant to how the jobs
were constructed. As it turned out, no such difference was actually exploited
by the test writers.mustang
device type can support both U-Boot and UEFI bootloaders but
not on the same machine at the same time. The bootloader can be changed, but
this is a custom process which is not manageable during a test job. In the
Cambridge lab, mustang
implies U-Boot and a separate sub device-type
called mustang-uefi
is available for test jobs needing UEFI.panda
devices can support operating systems like Debian as well as
supporting Android deployments using the same bootloader in both cases -
U-Boot. Therefore only one device type was needed here.The device type exists as a django database object which can be modified using the django admin interface. The following fields are supported:
/etc/lava-server/dispatcher-config/device-types/
,
without the .jinja2
suffix.The device type database also includes some optional fields which may be completed by the admin to provide information for test writers:
Note
When modifying device type objects in the Django administration interface, take care with multiple selection boxes. Fields like architecture name or alias can show in the list as being available for selection in a device type object but only the selected line or lines will actually be saved as references within the device type object. The references will show up on the device type detail page in the Information tab.