Hi everyone,
I'm a newbie to LAVA, so this may be a stupid question, but I have no idea how to fix this issue. I am using a device for which I enabled the usage of the second serial port as described in the example beaglebone-black job with a second serial port - it seems that the configuration works fine, I was able to enable the secondary connection.
The problem is the following: the second serial port connects to a different shell, which at this moment is used for freeRTOS application, and its prompt ("SHELL>>") is different of the primary connection prompt which is used for Linux("root@imx8mqevk"). When trying to actually run some commands on freeRTOS, I get timeout error and I have no idea how to fix it.
I attached to this e-mail my test job definition, together with the log and the snip from my web.
Thanks in advance for your support,
Oana
[image: image.png] [image: image.png]
On Wed, 26 Sep 2018 at 15:28, Oana Ercus oana.ercus@linaro.org wrote:
Hi everyone,
I'm a newbie to LAVA, so this may be a stupid question, but I have no idea how to fix this issue. I am using a device for which I enabled the usage of the second serial port as described in the example beaglebone-black job with a second serial port - it seems that the configuration works fine, I was able to enable the secondary connection.
But *why* are you trying to use this support? Just because it exists, does not mean it can be used for something radically different. Multiple serial port support exists to solve problems with interleaved kernel messages. It is not about multiple, incompatible, shells.
What are you trying to execute on this RTOS shell?
The problem is the following: the second serial port connects to a different shell, which at this moment is used for freeRTOS application, and its prompt ("SHELL>>") is different of the primary connection prompt which is used for Linux("root@imx8mqevk"). When trying to actually run some commands on freeRTOS, I get timeout error and I have no idea how to fix it.
Support for multiple serial ports in LAVA still relies on the other serial ports behaving as POSIX shells. Your RTOS shell is not POSIX, it fails to accept a command to repeat the prompt.
- {"dt": "2018-09-26T09:52:44.645577", "lvl": "target", "msg": "Incorrect command parameter(s). Enter \"help\" to view a list of available commands."}
That is not POSIX behaviour.
Equally, I'm not sure why you are trying to access the second serial port on this device, the primary serial port works fine without interleaved kernel messages. Don't abuse the support for multiple serial ports when what you've actually got is multiple and incompatible shells, effectively a separate operating system.
I attached to this e-mail my test job definition, together with the log and the snip from my web.
In future, please just attach the job_log plain as a YAML file, it is much easier to read than a screenshot of the UI. which just wastes space.
Thanks in advance for your support,
Oana
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Hi Neil,
Thank you for you quick answer. See mine below.
On 9/26/2018 6:25:41 PM, Neil Williams neil.williams@linaro.org wrote: On Wed, 26 Sep 2018 at 15:28, Oana Ercus oana.ercus@linaro.org wrote:
Hi everyone,
I'm a newbie to LAVA, so this may be a stupid question, but I have no idea how to fix this issue. I am using a device for which I enabled the usage of the second serial port as described in the example beaglebone-black job with a second serial port - it seems that the configuration works fine, I was able to enable the secondary connection.
But *why* are you trying to use this support? Just because it exists, does not mean it can be used for something radically different. Multiple serial port support exists to solve problems with interleaved kernel messages. It is not about multiple, incompatible, shells.
*Oana Ercus:* As I mentioned in the first mail, I am really new in using LAVA, and the usage of the multiple serial port seemed to be the most suitable at a first sight, even if I read in the documentation that this support is used to solve problems with interleaved kernel messages.
What are you trying to execute on this RTOS shell?
*Oana Ercus:* The RTOS will be used to actually run the application I want to test - the post processing of the audio signal.
The problem is the following: the second serial port connects to a different shell, which at this moment is used for freeRTOS application, and its prompt ("SHELL>>") is different of the primary connection prompt which is used for Linux("root@imx8mqevk"). When trying to actually run some commands on freeRTOS, I get timeout error and I have no idea how to fix it.
Support for multiple serial ports in LAVA still relies on the other serial ports behaving as POSIX shells. Your RTOS shell is not POSIX, it fails to accept a command to repeat the prompt.
- {"dt": "2018-09-26T09:52:44.645577", "lvl": "target", "msg": "Incorrect command parameter(s). Enter \"help\" to view a list of available commands."}
That is not POSIX behaviour.
Equally, I'm not sure why you are trying to access the second serial port on this device, the primary serial port works fine without interleaved kernel messages. Don't abuse the support for multiple serial ports when what you've actually got is multiple and incompatible shells, effectively a separate operating system.
*Oana Ercus:* I understand, this makes sense, the reason I tried to use the second serial port was not the interleaved kernel message. I will better explain you the usecase, maybe you will have some suggestions for me. The device used is the I.MX8M EVK from NXP (I am actually working from NXP, trying to put in place the automated testing for the Audio Framework which will run on this product). Initially, the device runs Linux OS. Over the Linux OS, a hypervisor will be used to start the FreeRTOS, which will run on a separate core. The audio applications will run on FreeRTOS, and these are the ones that should be validated. Does LAVA also have support for controlling non-POSIX shells?
I attached to this e-mail my test job definition, together with the log and the snip from my web.
In future, please just attach the job_log plain as a YAML file, it is much easier to read than a screenshot of the UI. which just wastes space.
*Oana Ercus:* Yes, I will do this in future. It was the first time when I asked for help from community, and I wanted to give you all the details.
Thanks in advance for your support,
Oana
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
On Thu, 27 Sep 2018 at 10:55, Oana Ercus oana.ercus@linaro.org wrote:
Hi Neil,
Thank you for you quick answer. See mine below.
On 9/26/2018 6:25:41 PM, Neil Williams neil.williams@linaro.org wrote: On Wed, 26 Sep 2018 at 15:28, Oana Ercus oana.ercus@linaro.org wrote:
Hi everyone,
I'm a newbie to LAVA, so this may be a stupid question, but I have no idea how to fix this issue. I am using a device for which I enabled the usage of the second serial port as described in the example beaglebone-black job with a second serial port - it seems that the configuration works fine, I was able to enable the secondary connection.
But *why* are you trying to use this support? Just because it exists, does not mean it can be used for something radically different. Multiple serial port support exists to solve problems with interleaved kernel messages. It is not about multiple, incompatible, shells.
*Oana Ercus:* As I mentioned in the first mail, I am really new in using LAVA, and the usage of the multiple serial port seemed to be the most suitable at a first sight, even if I read in the documentation that this support is used to solve problems with interleaved kernel messages.
What are you trying to execute on this RTOS shell?
*Oana Ercus:* The RTOS will be used to actually run the application I want to test - the post processing of the audio signal.
Non-POSIX shells are not currently supported in LAVA.
The problem is the following: the second serial port connects to a different shell, which at this moment is used for freeRTOS application, and its prompt ("SHELL>>") is different of the primary connection prompt which is used for Linux("root@imx8mqevk"). When trying to actually run some commands on freeRTOS, I get timeout error and I have no idea how to fix it.
Support for multiple serial ports in LAVA still relies on the other serial ports behaving as POSIX shells. Your RTOS shell is not POSIX, it fails to accept a command to repeat the prompt.
- {"dt": "2018-09-26T09:52:44.645577", "lvl": "target", "msg": "Incorrect
command parameter(s). Enter \"help\" to view a list of available commands."}
That is not POSIX behaviour.
Equally, I'm not sure why you are trying to access the second serial port on this device, the primary serial port works fine without interleaved kernel messages. Don't abuse the support for multiple serial ports when what you've actually got is multiple and incompatible shells, effectively a separate operating system.
*Oana Ercus:* I understand, this makes sense, the reason I tried to use the second serial port was not the interleaved kernel message. I will better explain you the usecase, maybe you will have some suggestions for me. The device used is the I.MX8M EVK from NXP (I am actually working from NXP, trying to put in place the automated testing for the Audio Framework which will run on this product). Initially, the device runs Linux OS. Over the Linux OS, a hypervisor will be used to start the FreeRTOS, which will run on a separate core. The audio applications will run on FreeRTOS, and these are the ones that should be validated. Does LAVA also have support for controlling non-POSIX shells?
No. It's not clear how to support such shells because every non-POSIX shell is different - POSIX is a standard, there is nothing standard about the shells which do not comply with POSIX and it's not as if there is a standard competing with POSIX. LAVA has no way of knowing what to expect from such a shell - error messages, execution of commands, expected output.
The closest is the IoT support - the monitor test - which requires that everything is started automatically, that there are clear and unique start & end messages and that the output in between can be predictably parsed to generate results.
https://staging.validation.linaro.org/scheduler/job/240077/definition
The test monitors support is designed for validating the output of Zephyr on IoT boards. It is not interactive in any way, it cannot issue commands - all processing is done solely on passively parsing automatic output which has been pre-programmed into the DUT and which starts automatically from power on.
I attached to this e-mail my test job definition, together with the log and the snip from my web.
In future, please just attach the job_log plain as a YAML file, it is much easier to read than a screenshot of the UI. which just wastes space.
*Oana Ercus:* Yes, I will do this in future. It was the first time when I asked for help from community, and I wanted to give you all the details.
Thanks in advance for your support,
Oana
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/
lava-users@lists.lavasoftware.org
-
Neil Williams -
Oana Ercus