The LAVA test job deploys a new linux kernel. Most DUTs are not capable of having a new U-Boot deployed in automation because there is no way to automatically recover from a broken deployment.
Please read through the documentation, starting with the first pipeline QEMU job and have a look at how existing test jobs work on LAVA instances like
staging.validation.linaro.org
It sounds like you are approaching this with a fixed set of assumptions, based on some existing tooling?
LAVA supports deploying new software builds to real hardware under automation. Typically that means a new kernel and root filesystem (so there would be nowhere for a daemon to exist on the DUT as everything above the kernel is freshly deployed on every test job). *Some* hardware (out of over 100 device types, there are only 2 with this support) can automatically recover from a broken firmware / bootloader deployment and so can deploy a new build of U-Boot or UEFI for each test job. The two types are hikey 6220 (NOT 960) and Juno. Even so, there are limitations - for example only one hikey 6220 can be configured for automated firmware deployment on any one worker because the hikey 6220 does not uniquely identify itself when in recovery mode.
Please fully describe your use case, including details of the devices you want to test, how you want to test the software using those devices and how you will isolate testing of each component. (Change only one thing at a time - do not try to do full software stack testing with multiple changes per test run. Make the job matrix large enough that every change to every component is individually tested against known working versions of every other component.) If your device does support automated U-Boot deployment (the vast majority cannot - anything relying on U-Boot on an SD card cannot) then each change to U-Boot must be tested against a known working kernel and root filesystem. When you change the kernel, you keep to a known working U-Boot and root filesystem etc.
Do not make it a requirement to be able to reliably automate deployment of U-Boot, at scale. It is exceptionally rare to find a device which can support it. It generally involves the specific hardware designed into the device at the earliest stages to act as a baseboard management controller. This is not a limitation of the automation software, this is a reality of the hardware design of the DUT. LAVA has tested many attempts at making a device which can muiltiplex SD cards - NONE have proven to be reliable. To make automated testing work at scale demands high reliability and every additional layer of hardware (like SD card replacement or battery isolation) adds complexity and lowers reliability.