Hello All,
Background:: The armv8 models supports multiple uarts. The primary one being uart0. I believe this is the one which LAVA listens to, to provide the log message when tests are run.
Till now uart0 was the serial connection in use. However with our recent changes to the arm trusted firmware we introduced the test secure payload which is a test component in the secure world that is using uart1 for dumping its log info.
Issue::
I have to test in 2 configuration where
a) This test secure payload is included
b) This test secure payload is excluded (which is the default case when using the standard make file flags)
For the second config, this are all perfect, no issues.
However for the first config when this test secure payload is there that uses uart0, I can see that the kernel does to complete the boot sequence. When run with the same firmware and the filesystem, it works perfectly OK.
The key observation is that lava log output abruptly stops after the file system is mounted and just before we expect messages about udev bindings (in a successful run I see some udev messages and almost immediately the 'Last login' message which cue for lava to confirm the boot was successful).
There were 2 additional flags which the developer was using in his manual run and I gave that too in the device config, but in vain!
bp.pl011_uart0.out_file=- (when I included this lava started throwing duplicate set of messages in the log! So I removed it later) bp.pl011_uart1.out_file=tsp.output
Attaching the lava log outputs both with and without tsp component as reference.
It is clear to me that the images boots successfully, however LAVA seem to lose serial communication in between which makes it impossible to detect the login prompt.
Any obvious suspicions on this differing behaviour? Any help much appreciated.
Thanks Basil Eljuse...
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Basil; Thanks for your input. Would you mind filing a ticket on http://support.linaro.org/ so these requests are managed through our support system? With Connect this week, I want to make sure that they are not forgotten.
I also think that this may be a great issue we need to work on as a roadmap item to support the secure models. If we can scope out an effort for integrating secure fastmodels, we can plan for an engineer to be dedicated to integrating the new behavior/device/workflow you are describing. Right now, I don't think we have much experience with the workflow you describe and I'm not sure we can be much help.
Best Regards; Alan
On 23 February 2014 07:18, Basil Eljuse Basil.Eljuse@arm.com wrote:
Hello All,
*Background::*
The armv8 models supports multiple uarts. The primary one being uart0. I believe this is the one which LAVA listens to, to provide the log message when tests are run.
Till now uart0 was the serial connection in use. However with our recent changes to the arm trusted firmware we introduced the test secure payload which is a test component in the secure world that is using uart1 for dumping its log info.
*Issue::*
I have to test in 2 configuration where
a) This test secure payload is included
b) This test secure payload is excluded (which is the default case when using the standard make file flags)
For the second config, this are all perfect, no issues.
However for the first config when this test secure payload is there that uses uart0, I can see that the kernel does to complete the boot sequence.
When run with the same firmware and the filesystem, it works perfectly OK.
The key observation is that lava log output abruptly stops after the file system is mounted and just before we expect messages about udev bindings (in a successful run I see some udev messages and almost immediately the ‘Last login’ message which cue for lava to confirm the boot was successful).
There were 2 additional flags which the developer was using in his manual run and I gave that too in the device config, but in vain!
bp.pl011_uart0.out_file=- (when I included this lava started throwing duplicate set of messages in the log! So I removed it later)
bp.pl011_uart1.out_file=tsp.output
Attaching the lava log outputs both with and without tsp component as reference.
It is clear to me that the images boots successfully, however LAVA seem to lose serial communication in between which makes it impossible to detect the login prompt.
Any obvious suspicions on this differing behaviour? Any help much appreciated.
Thanks
Basil Eljuse…
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
Thanks Alan,
I’ve created a ticket in Linaro support
Request #728 "LAVA unable to support fast..." created
Andrew Thoelke is at Linaro connect. I know he is presenting a session on trusted firmware. He is one of the technical leads on arm trusted firmware project and will be a good contact point if you would need any specific detail on trusted firmware components and its use of peripherals ( from secure world).
Thanks Basil Eljuse…
From: Alan Bennett [mailto:alan.bennett@linaro.org] Sent: 25 February 2014 14:28 To: Basil Eljuse Cc: Linaro Validation; Dean Arnold Subject: Re: [Linaro-validation] How does LAVA handle the multiple uart outputs from models?
Basil; Thanks for your input. Would you mind filing a ticket on http://support.linaro.org/ so these requests are managed through our support system? With Connect this week, I want to make sure that they are not forgotten.
I also think that this may be a great issue we need to work on as a roadmap item to support the secure models. If we can scope out an effort for integrating secure fastmodels, we can plan for an engineer to be dedicated to integrating the new behavior/device/workflow you are describing. Right now, I don't think we have much experience with the workflow you describe and I'm not sure we can be much help.
Best Regards; Alan
On 23 February 2014 07:18, Basil Eljuse <Basil.Eljuse@arm.commailto:Basil.Eljuse@arm.com> wrote: Hello All,
Background:: The armv8 models supports multiple uarts. The primary one being uart0. I believe this is the one which LAVA listens to, to provide the log message when tests are run.
Till now uart0 was the serial connection in use. However with our recent changes to the arm trusted firmware we introduced the test secure payload which is a test component in the secure world that is using uart1 for dumping its log info.
Issue::
I have to test in 2 configuration where
a) This test secure payload is included
b) This test secure payload is excluded (which is the default case when using the standard make file flags)
For the second config, this are all perfect, no issues.
However for the first config when this test secure payload is there that uses uart0, I can see that the kernel does to complete the boot sequence. When run with the same firmware and the filesystem, it works perfectly OK.
The key observation is that lava log output abruptly stops after the file system is mounted and just before we expect messages about udev bindings (in a successful run I see some udev messages and almost immediately the ‘Last login’ message which cue for lava to confirm the boot was successful).
There were 2 additional flags which the developer was using in his manual run and I gave that too in the device config, but in vain!
bp.pl011_uart0.out_file=- (when I included this lava started throwing duplicate set of messages in the log! So I removed it later) bp.pl011_uart1.out_file=tsp.output
Attaching the lava log outputs both with and without tsp component as reference.
It is clear to me that the images boots successfully, however LAVA seem to lose serial communication in between which makes it impossible to detect the login prompt.
Any obvious suspicions on this differing behaviour? Any help much appreciated.
Thanks Basil Eljuse…
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.orgmailto:linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
--
Alan Bennett, Engineering Manager, Linaro LAVA Team Linaro.orghttp://www.linaro.org/ │ Open source software for ARM SoCs | Follow Linaro: Facebookhttp://www.facebook.com/pages/Linaro | Twitterhttp://twitter.com/#%21/linaroorg | Bloghttp://www.linaro.org/linaro-blog/ irc: akbennett | alan.bennett@linaro.orgmailto:alan.bennett@linaro.org | linaro-validation@lists.linaro.orgmailto:linaro-validation@lists.linaro.org
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
linaro-validation@lists.linaro.org
-
Alan Bennett -
Basil Eljuse