On Mon, 10 Dec 2018 at 08:52, Larry Shen larry.shen@nxp.com wrote:
Got it.
But, let me make the problem more generic not just for adb fastboot.
If I have two methods to burn one device, and I have two device types, if possible for user to dynamic switch between two device types with only one device?
One device cannot serve two device-types.
* If the same hardware device can boot method A, run a test and finish that test job and then (immediately and seamlessly) boot method B and run a different test, then revert to either boot method A or B in any order - all without any admin intervention, then the two device-types need to be merged into a single device-type - e.g. there is support for using fastboot via U-Boot whilst still retaining TFTP support for U-Boot on the same hardware.
* If the hardware needs admin intervention to get from method A to method B or from B back to A, then you will need to obtain another piece of hardware or your CI simply cannot operate. You then set up 1 device permanently in the configuration to boot method A and another device permanently in the configuration to boot method B.
* Some hardware can change from UEFI to U-Boot and back again within consecutive test jobs but support for this is *rare* - only one device-type out of the hundreds supported by LAVA can do this. Again, this must be completely reliable and entirely automated. https://master.lavasoftware.org/static/docs/v2/bootloaders.html#bootloader-f...
CI relies on jobs being submitted 24/7 365 days a year and those jobs are organised into a queue. Every device needs to be able to pick up the next device in the queue without *any* reliance on whatever test job was last run on that device. Test jobs are independent.
This isn't about LAVA particularly, this is the difference between a multi-user CI system where the submitter has no need to know anything about the history of the device and a device on your desk where that knowledge is always available.
(Also, I'd recommend not using the term "burn" for what is actually a deployment. Permanence and persistence are typically *bad* ideas in CI.)
Regards, Larry
-----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org] Sent: Monday, December 10, 2018 4:47 PM To: Larry Shen larry.shen@nxp.com Cc: lava-users@lists.lavasoftware.org Subject: Re: [Lava-users] How to switch device-type base jinja with only one device?
On Mon, 10 Dec 2018 at 08:39, Larry Shen larry.shen@nxp.com wrote:
Dear all,
I have a question when use lava.
Background:
I have only one hardware device with android.I have a device-type jinja2 file start with “{% extends 'base-fastboot.jinja2' %}”Here, I use “adb reboot bootloader” to enter in to fastboot.
Avoid that at all costs. adb is not safe as a means of rebooting the device because it completely relies on the previous test job getting to the point where adb is even available *AND* is relies on the previous test job leaving adb even enabled in the deployed image. That kind of assumption will fail.
I have another device-type jinja2 file start with “{% extends 'base-uboot.jinja2' %}”Here, I use “fastboot 0” in uboot to enter in to fastboot.
You need remote power control which does not rely on adb.
Now, we have a scenario which need to test with above both methods, but we just have one device, if possible user can define some parameter in job.yaml, then can switch between the two methods just for one device? Any suggestion?
Drop the reliance on adb.
See the x15.jinja2 for a device-type which uses U-Boot to get to fastboot.
--
Neil Williams
neil.williams@linaro.org https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linux....