Hi, Remi,
A little late, just back from my vacation.
This is for our health check job:
1. We want to let health-check job automatically recover bootloader, once there is a job incomplete(possible bootloader crash in a regular job)
2. The side effect: the health check ran periodic, which means from time to time uuu will flash the board even the board is ok. That’s a waste, and furthermore, may bring failure
point if at that time the usb is not stable.
According to conventional: “we only recover the board with UUU if the board can’t start”, this sounds more reasonable.
Additional, currently in NXP internal, we have “imx8mp-evk” & “imx8mp-evk-no-usb” variant because we need
to have 2 different kinds of health-check for board with usb and without usb linked (the difference due to hardware conflict). It’s somewhat not convenient for a “test job generator based on job template”, as from testcase level, the case may can run on both
kinds of boards; but when automatically define job we have to choose one & omit another currently. So, I’m thinking if it’s better to just use “imx8mp-evk”, use tag to distinguish “usb”, “-no-usb” flavor, then for one testcase, we could just send it to “imx8mp-evk”
device; otherwise the “imx8mp-evk-no-usb” lose the chance to run the case though these boards are idle.
And if LAVA static pipeline can’t meet the requirement, do you think it’s reasonable to add that “if” to uuu action?
Regards,
Larry
From: Remi Duraffort <remi.duraffort@linaro.org>
Sent: Tuesday, October 3, 2023 4:43 PM
To: Larry Shen <larry.shen@nxp.com>
Cc: lava-users@lists.lavasoftware.org
Subject: [EXT] Re: [lava-users] Search conditional logic in job or something else could be act as workaround.
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email'
button |
Hello,
Le ven. 22 sept. 2023 à 09:23, Larry Shen <larry.shen@nxp.com> a écrit :
Hi, guys,
I currently have 2 jobs:
Job1:
actions:
- boot:
failure_retry: 4
method: bootloader
bootloader: u-boot
commands: []
prompts: ['=>']
timeout:
minutes: 2
- test:
timeout:
minutes: 4
interactive:
- name: check-uboot
prompts: ["=> ", "/ # "]
script:
- command: "printenv"
name: printenv
successes:
- message: "soc_type=imx93"
Job2:
actions:
- deploy:
to : uuu
images :
boot :
url : /path/to/bootloader
- boot:
method: uuu
commands :
- bcu: reset usb
- uuu: -b sd {boot}
- bcu: deinit
timeout:
minutes: 2
- boot:
method: bootloader
bootloader: u-boot
commands: []
prompts: ['=>']
timeout:
minutes: 2
- test:
interactive:
- name: check-uboot
prompts: ["=> ", "/ # "]
script:
- command: "printenv"
name: printenv
successes:
- message: "soc_type=imx93"
timeout:
minutes: 2
The first job just boot the board and check if the bootloader ok, the second job flash a new bootloader to board everytime before check the bootloader.
I wonder if possible for me to combine the two, define next logic in a job:
1. Boot the board to check the uboot
2. If uboot is ok, then the job finish
3. If uboot not ok or action timeout, then go to flash action to flash new bootloader to the device, then job finish.
The idea is: the step 3 is optional, we only flash a new bootloader when previous boot action failure.
There is currently no way for LAVA to successfully finish a job without running the full pipeline. It would be possible to use an interactive test definition to raise an exception when the right bootloader is found.
What are you trying to achieve exactly? (there is maybe another way to do it).
Rgds
--
Rémi Duraffort
Principal Tech Lead
LAVA Tech Lead
Automation Software Team
Linaro