the board uefi use dialog to boot, how can I configuare the lava device-type config file.
hi, all,
The uefi the board used has upgraded, so that the configuration of it can not be used in the current environment. Because now the uefi use the dialog to show the menu.
As I know, the expect and sendline in the lava XXX.conf can not work well in this situation. Does you know how to config the XXX.conf to support this kind of uefi?
The menu of the uefi is below.
and
Thank you very much.
Elaine (wuyanjun)
Hisilicon, Turing Architecture and Software
There is experimental UEFI menu support in LAVA pipeline V2 - it works on the lava-dispatch command line for an XGene Mustang with UEFI menu but there are problems with the submission through the UI with escape characters.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Juno devices have menu support in LAVA V1: https://git.linaro.org/lava/lava-lab.git/blob/HEAD:/validation.linaro.org/la...
However, issues will persist:
1: Menus that use more complex structures will fail to parse - typically this will be if the menu uses curses of similar interface instead of line-based. 2: The current support is for a limited set of devices and UEFI builds and each one can require integration. 3: a UEFI shell is a preferred option for automation - many uses of the menus only use enough of the menu to get to a shell. 4. Unless you are actually testing the UEFI build, you can avoid UEFI entirely by pre-configuring something like grub on top and interacting with the a shell provided by that. Make a decision about whether the UEFI on these devices is something you are explicitly testing or simply using to get to a system that can run your tests. If you want to test both, consider having one device-type which uses an unchanging UEFI build and one device-type that updates the UEFI on each build. That device-type needs a way of recovering if the UEFI build is broken - that support depends on the hardware. 5. The aim with UEFI would be that it does become mostly unchanging and that it provides a common interface to the kernel across different device types. So for kernel testing, a static UEFI build is the right answer so that tests only involve one changing element each run.
On 22 March 2016 at 11:51, Elaine Wu (wuyanjun) wu.wu@hisilicon.com wrote:
hi, all,
The uefi the board used has upgraded, so that the configuration of it can not be used in the current environment. Because now the uefi use the dialog to show the menu.
As I know, the expect and sendline in the lava XXX.conf can not work well in this situation. Does you know how to config the XXX.conf to support this kind of uefi?
The menu of the uefi is below.
and
Thank you very much.
Elaine (wuyanjun)
Hisilicon, Turing Architecture and Software
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
hi, Neil,
Thank you for your reply.
I am using the LAVA V1, and I read the juno.conf file. But I don't have a Juno board, so I can not understand the config well. What is the meaning of 'sendcontrol' in the config file?
Does 'sendcontrol [' will let the cursor move in the menu or select the item in the menu lists? If so, how do I know the meaning of values in the sendcontrol?
Now What I want only is to go to the Shell in uefi and then boot the system and run tests. I am not testing the UEFI.
Thank you
Elaine (wuyanjun)
Hisilicon, Turing Architecture and Software
On 2016/3/22 21:10, Neil Williams wrote:
There is experimental UEFI menu support in LAVA pipeline V2 - it works on the lava-dispatch command line for an XGene Mustang with UEFI menu but there are problems with the submission through the UI with escape characters.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Juno devices have menu support in LAVA V1: https://git.linaro.org/lava/lava-lab.git/blob/HEAD:/validation.linaro.org/la...
However, issues will persist:
1: Menus that use more complex structures will fail to parse - typically this will be if the menu uses curses of similar interface instead of line-based. 2: The current support is for a limited set of devices and UEFI builds and each one can require integration. 3: a UEFI shell is a preferred option for automation - many uses of the menus only use enough of the menu to get to a shell. 4. Unless you are actually testing the UEFI build, you can avoid UEFI entirely by pre-configuring something like grub on top and interacting with the a shell provided by that. Make a decision about whether the UEFI on these devices is something you are explicitly testing or simply using to get to a system that can run your tests. If you want to test both, consider having one device-type which uses an unchanging UEFI build and one device-type that updates the UEFI on each build. That device-type needs a way of recovering if the UEFI build is broken
- that support depends on the hardware.
- The aim with UEFI would be that it does become mostly unchanging
and that it provides a common interface to the kernel across different device types. So for kernel testing, a static UEFI build is the right answer so that tests only involve one changing element each run.
On 22 March 2016 at 11:51, Elaine Wu (wuyanjun) <wu.wu@hisilicon.com mailto:wu.wu@hisilicon.com> wrote:
hi, all, The uefi the board used has upgraded, so that the configuration of it can not be used in the current environment. Because now the uefi use the dialog to show the menu. As I know, the expect and sendline in the lava XXX.conf can not work well in this situation. Does you know how to config the XXX.conf to support this kind of uefi? The menu of the uefi is below. and Thank you very much. Elaine (wuyanjun) Hisilicon, Turing Architecture and Software _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org <mailto:Lava-users@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/lava-users--
Neil Williams
neil.williams@linaro.org mailto:neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On 23 March 2016 at 03:49, Elaine Wu (wuyanjun) wu.wu@hisilicon.com wrote:
hi, Neil,
Thank you for your reply.
I am using the LAVA V1, and I read the juno.conf file. But I don't have a Juno board, so I can not understand the config well. What is the meaning of 'sendcontrol' in the config file?
Does 'sendcontrol [' will let the cursor move in the menu or select the item in the menu lists? If so, how do I know the meaning of values in the sendcontrol?
sendcontrol sends the value as if the Ctrl button was pressed at the same time. So 'sendcontrol B' causes Ctrl-B to be sent. How that gets interpreted is down to the actual menu handling. Movement between items in a menu is likely to be problematic - menus are easier to support when the options are numbered and the number can be entered as ASCII.
Now What I want only is to go to the Shell in uefi and then boot the system
and run tests. I am not testing the UEFI.
Investigate whether UEFI can be persuaded to load a bootloader like Grub as this has a usable shell to allow you to boot a test kernel. If not, you could pre-configure UEFI to drop to a shell without needing interaction.
Thank you
Elaine (wuyanjun)
Hisilicon, Turing Architecture and Software
On 2016/3/22 21:10, Neil Williams wrote:
There is experimental UEFI menu support in LAVA pipeline V2 - it works on the lava-dispatch command line for an XGene Mustang with UEFI menu but there are problems with the submission through the UI with escape characters.
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/te...
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/p...
Juno devices have menu support in LAVA V1:
https://git.linaro.org/lava/lava-lab.git/blob/HEAD:/validation.linaro.org/la...
However, issues will persist:
1: Menus that use more complex structures will fail to parse - typically this will be if the menu uses curses of similar interface instead of line-based. 2: The current support is for a limited set of devices and UEFI builds and each one can require integration. 3: a UEFI shell is a preferred option for automation - many uses of the menus only use enough of the menu to get to a shell. 4. Unless you are actually testing the UEFI build, you can avoid UEFI entirely by pre-configuring something like grub on top and interacting with the a shell provided by that. Make a decision about whether the UEFI on these devices is something you are explicitly testing or simply using to get to a system that can run your tests. If you want to test both, consider having one device-type which uses an unchanging UEFI build and one device-type that updates the UEFI on each build. That device-type needs a way of recovering if the UEFI build is broken - that support depends on the hardware. 5. The aim with UEFI would be that it does become mostly unchanging and that it provides a common interface to the kernel across different device types. So for kernel testing, a static UEFI build is the right answer so that tests only involve one changing element each run.
On 22 March 2016 at 11:51, Elaine Wu (wuyanjun) wu.wu@hisilicon.com wrote:
hi, all,
The uefi the board used has upgraded, so that the configuration of it can not be used in the current environment. Because now the uefi use the dialog to show the menu.
As I know, the expect and sendline in the lava XXX.conf can not work well in this situation. Does you know how to config the XXX.conf to support this kind of uefi?
The menu of the uefi is below.
and
Thank you very much.
Elaine (wuyanjun)
Hisilicon, Turing Architecture and Software
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
hi, Neil,
I have tried to rewrite the new config file. Because the uefi is provided by other teams so if I need to enter the grub I must to select the ufei menu.
Now when I testing the new config file, it get stuck. I think it is strange.
The config file looks like below: || expect "or any other key to continue.",|| sendline "False",|| expect "Shell>",|| sendline exit, -------------> this sentence stuck|| expect 'Select Language',||sendcontrol [,|| sendcontrol M,|| expect "GNU GRUB",|| sendline c,||expect grub>,|| The lava log is below: |9.21 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_9_21 [1m[33m[40m BLK0:[0m[37m[40m [1m[37m[40mAlias(s):[0m[37m[40m||9.22 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_9_22 Pci(0x0,0x0)/Pci(0x0,0x0)| Section 10 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_10 |10.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_10_0 [11;01HPress [1m[37m[40mESC[0m[37m[40m in 5 seconds to skip [1m[33m[40mstartup.nsh[0m[37m[40m or any other key to continue.2016-03-23 08:51:20 AM DEBUG: send (delay_ms=0): False||10.1 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_10_1 2016-03-23 08:51:20 AM DEBUG: send (delay_ms=0):||10.2 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_10_2 2016-03-23 08:51:20 AM DEBUG: send (delay_ms=0):| Section 11 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_11 |11.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_11_0 | Section 12 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_12 |12.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_12_0 2016-03-23 08:51:20 AM DEBUG: expect (1200): 'Shell>'| Section 13 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_13 |13.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_13_0 | Section 14 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_14 |14.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_14_0 [12;01H[1m[33m[40mShell> 2016-03-23 08:51:21 AM DEBUG: send (delay_ms=0): exit -----------> send the 'exit' command to uefi 'Shell>'||14.1 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_14_1 2016-03-23 08:51:21 AM DEBUG: send (delay_ms=0):||14.2 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_14_2 2016-03-23 08:51:21 AM DEBUG: send (delay_ms=0):| Section 15 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_15 |15.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_15_0 | Section 16 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_16 |16.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_16_0 2016-03-23 08:51:21 AM DEBUG: expect (1200): 'Select\ Language'| Section 17 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_17|17.0 http://htsat.vicp.cc:800/scheduler/job/639/log_file#L_17_0 [0m[37m[40m[12;08Ha[12;09H[12;09Hl[12;10H[12;10Hs[12;11H[12;11He[12;12H[12;12H[12;12He[12;13H[12;13Hx[12;14H[12;14Hi[12;15H[12;15Ht[12;16H[12;16H ----------------------> stuck|||| | But when I do it manually, it can work well. Have you encounter this situation before? Do you have any solution?
Thanks very much
Elaine (wuyanjun) Hisilicon, Turing Architecture and Software
On 2016/3/23 17:10, Neil Williams wrote:
On 23 March 2016 at 03:49, Elaine Wu (wuyanjun) <wu.wu@hisilicon.com mailto:wu.wu@hisilicon.com> wrote:
hi, Neil, Thank you for your reply. I am using the LAVA V1, and I read the juno.conf file. But I don't have a Juno board, so I can not understand the config well. What is the meaning of 'sendcontrol' in the config file? Does 'sendcontrol [' will let the cursor move in the menu or select the item in the menu lists? If so, how do I know the meaning of values in the sendcontrol?sendcontrol sends the value as if the Ctrl button was pressed at the same time. So 'sendcontrol B' causes Ctrl-B to be sent. How that gets interpreted is down to the actual menu handling. Movement between items in a menu is likely to be problematic - menus are easier to support when the options are numbered and the number can be entered as ASCII.
Now What I want only is to go to the Shell in uefi and then boot the system and run tests. I am not testing the UEFI.Investigate whether UEFI can be persuaded to load a bootloader like Grub as this has a usable shell to allow you to boot a test kernel. If not, you could pre-configure UEFI to drop to a shell without needing interaction.
Thank you Elaine (wuyanjun) Hisilicon, Turing Architecture and Software On 2016/3/22 21:10, Neil Williams wrote:There is experimental UEFI menu support in LAVA pipeline V2 - it works on the lava-dispatch command line for an XGene Mustang with UEFI menu but there are problems with the submission through the UI with escape characters. https://git.linaro.org/lava/lava-server.git/blob/HEAD:/lava_scheduler_app/tests/device-types/mustang-uefi.jinja2 https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/pipeline/devices/mustang-uefi.yaml Juno devices have menu support in LAVA V1: https://git.linaro.org/lava/lava-lab.git/blob/HEAD:/validation.linaro.org/lava/device-types/juno.conf However, issues will persist: 1: Menus that use more complex structures will fail to parse - typically this will be if the menu uses curses of similar interface instead of line-based. 2: The current support is for a limited set of devices and UEFI builds and each one can require integration. 3: a UEFI shell is a preferred option for automation - many uses of the menus only use enough of the menu to get to a shell. 4. Unless you are actually testing the UEFI build, you can avoid UEFI entirely by pre-configuring something like grub on top and interacting with the a shell provided by that. Make a decision about whether the UEFI on these devices is something you are explicitly testing or simply using to get to a system that can run your tests. If you want to test both, consider having one device-type which uses an unchanging UEFI build and one device-type that updates the UEFI on each build. That device-type needs a way of recovering if the UEFI build is broken - that support depends on the hardware. 5. The aim with UEFI would be that it does become mostly unchanging and that it provides a common interface to the kernel across different device types. So for kernel testing, a static UEFI build is the right answer so that tests only involve one changing element each run. On 22 March 2016 at 11:51, Elaine Wu (wuyanjun) <wu.wu@hisilicon.com <mailto:wu.wu@hisilicon.com>> wrote: hi, all, The uefi the board used has upgraded, so that the configuration of it can not be used in the current environment. Because now the uefi use the dialog to show the menu. As I know, the expect and sendline in the lava XXX.conf can not work well in this situation. Does you know how to config the XXX.conf to support this kind of uefi? The menu of the uefi is below. and Thank you very much. Elaine (wuyanjun) Hisilicon, Turing Architecture and Software _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org <mailto:Lava-users@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/lava-users -- Neil Williams ============= neil.williams@linaro.org <mailto:neil.williams@linaro.org> http://www.linux.codehelp.co.uk/--
Neil Williams
neil.williams@linaro.org mailto:neil.williams@linaro.org http://www.linux.codehelp.co.uk/
-
Elaine Wu (wuyanjun) -
Neil Williams