On 18 December 2017 at 13:42, Philippe BEGNIC <philippe.begnic@st.com> wrote:
Thank you Neil for your answer,
Find my comments below.
On 12/18/2017 02:32 PM, Neil Williams wrote:
On 18 December 2017 at 10:12, Philippe BEGNIC <philippe.begnic@st.com> wrote:
Hello Lava Team,
I have created some Lava jobs that use our proprietary Flasher, based on a DFU connection.
As our flasher is not a "standard" flasher, I have adapted the boot process to be able to use our flasher.
Sounds like you need to use LXC instead. Put the flashing tool inside the LXC.
The board I am testing is installed in a debian docker, and the flashing tools is installed in this docker.
That doesn't remove the need for LXC.
Separation that allows the use of namespaces to set the version of the flashing tool in a test shell.
I use the boot method "minimal" to achieve this.
To call our flasher script, I have used the script called by the method "power_on". This is defined in the device configuration.
Find below an extract of the device content :
.......................................................................................
..
..
{% set hard_reset_command = '/usr/bin/pduclient --daemon localhost --hostname
lava_pdu_01.lme.st.com --command reboot --port 1' %}
{% set power_off_command = '/usr/bin/pduclient --daemon localhost --hostname
lava_pdu_01.lme.st.com --command off --port 1' %}
{% set power_on_command = '/root/git/lava-config/scripts/flash_stm32_programmer.sh -u
lava_pdu_01.lme.st.com -p 1 -d usb1 -b
ds378_2.lme.st.com -s 4_5_6 -f /tmp/test' %}
{% set connection_command = 'telnet localhost 2001' %}
..
..
.......................................................................................
This works correctly for a "static" configuration. The settings for the flasher are defined outside Lava by a script that configure the flashing parameters.
That script should be run inside the LXC.
However, it looks like you're approaching this in the wrong way anyway - if you are flashing files to the device, that is NOT a power on command. That is a deployment action which needs to be done in the LXC because you need to separate
different versions of the flashing tool from each other, based on the test job.
Ignore docker in all this, that's just how you've got LAVA installed. You can't have a separate dispatcher for every test job. Use LXC to have a separate environment which the one dispatcher uses to configure the flashing tool for that
specific test job.
The "power_on" script reads these parameters, and launch the flashing on the board.
My problem now, is when I launch simultaneously jobs on several boards that requires different flashing binaries version.
I am unable to indicate to each boards which binary version to be used by our flasher.
So each needs to set up their own in a container.
Each devices under test is installed in a docker.
Doesn't make any odds, you should not reconfigure the docker for each test job, that is the role for LXC, transparently within LAVA.
The best way would be to pass parameters in the job to indicate which binary version has to be used by the flasher.
No, that is a very bad way.
What would be the problem to use this method ?
Parameters are only passed to a test shell. The flashing tool needs to be configured afresh within each test job - the supported way to do that is LXC.
This could be done in the "deploy action" and pass to the "power_on" command, but I don't know how to implement it.
I don't know also if it is possible to do that easily ?
Find below my job definition.
###### Job definition ##############
download_command: sync && sleep 15 && wget
unpack_command: tar -C / -xzf
- test: ... #############################
Thanks to support me.
BR
Philippe
_______________________________________________
Lava-users mailing list
Lava-users@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lava-users
--