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
Hello All,
I thought this is worth sharing.
As part of testing current release of trusted firmware, I had been using LAVA to do a subset of tests which are supported, as there were some configs not yet supported.
As part of that I gave a go at trying to run some baremetal tests with an interesting outcome.
The various binary blobs involved::
Till now we had separate set of bootloader images for trusted firmware like bl1.bin, bl2.bin, bl31.bin. So we used to specify the following fastmodel arguments
-C bp.flashloader0.fname=<path_to_uefi> -C bp.secureflashloader.fname=<path_to_bl1>
and the rest of the bl images located by fastmodel using the semihosting cwd flag => -C cluster0.cpu0.semihosting-cwd=<semihosting_dir_path>
However with this latest release trusted firmware introduced a single binary package called Firmware Image Package (fip) which is a bundle of bl2 and various bl3 images.
With this change we specify the below flag as
-C bp.flashloader0.fname=<path_to_fip>
which has all the needed firmware images. There is a fip tool that allows one to replace any of the individual packaged binaries with a new one.
How baremetal test fips are generated?
Using the above mentioned fip tool we replace the uefi image in the fip image which is one of the BL3 images, with our baremetal test binary.
With this recreated fip if I launch a job with LAVA, it actually executes the test.
Few glitches
I still specify that the boot loader is uefi. But LAVA executes it irrespective of this and ends up timing out and obviously retries 2 more times as usual. (It is just stress testing for the component because some of my tests do run for ever, so having the test run over an hour doing repeated suspend or powerdown calls and having to repeat it 3 times overall in a single run sound a really good side-effect of this 'problem'!)
My overall test run shows an 'Incomplete' status understandably!
Please note that our current baremetal tests are bit primitive in the sense they do not have a test framework or harness but each test is a self contained test code implementing a test case. In future we will have a decent shaped baremetal test harness / framework. This would mean I may not 'get lucky' like this time. The complexity would be different so don't want to leave any wrong impression that this could serve my needs even in future.
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
Hi,
Anyone can help to check if the filter works on the All Jobs page of LAVA?
https://validation.linaro.org/scheduler/alljobs
I can access the jobs, but on the above page,
when I select 50 or 100 from the select box of show entries, it does not
work.
when I input text into the Search textbox, it does not work too.:(
Can anyone help to check if it's just problem of my side?
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
Oops forgot the logs to be attached!
From: Basil Eljuse
Sent: 23 February 2014 14:19
To: Linaro Validation
Cc: Dean Arnold
Subject: How does LAVA handle the multiple uart outputs from models?
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
https://bugs.launchpad.net/lava-server/+bug/1271527
device_tags have been ignored by the LAVA scheduler for a while and
many of the example JSON files, especially the multinode ones, include
arbitrary tags:
https://validation.linaro.org/scheduler/job/108452/multinode_definition
"device_type": "panda",
"tags": [
"codehelp-crim"
]
In this example, "codehelp-crim" is a false, arbitrary tag - used only
to illustrate the syntax for MultiNode jobs which would use the tags
appropriately.
device_tags for singlenode jobs have already been fixed so that unknown
tags are rejected at submission time. The same support is being added
to MultiNode submissions, along with support for ensuring that the tags
are taken into account when singlenode or multinode jobs are assigned
from the queue. This is to restore the designed support for device_tags
and fix the bug.
The bug is due to be fixed soon - at which point tags which are *not*
supported by the instance to which the job is submitted will cause the
job submission to *fail*. This is so that device tags can be used to
dictate which devices actually run the TestJob.
I'll be updating the functional tests and the multinode use case
JSON examples before the bug fix lands in staging.
The device_tags supported by a specific device are already visible in
LAVA on the device detail page for that device. e.g.
https://validation.linaro.org/scheduler/device/panda05
Therefore, if the job required the use of particular support, the above
tags *could* be allowed if changed to:
"device_type": "panda",
"tags": [
"audio-loopback",
"usb-flash-drive"
]
Tags are device-specific and some devices have no tags at all. The tags
list could simply be removed if the TestJob has no particular
requirement for the support provided by the tags or if no tags are
supported for the device:
"device_type": "panda"
Specifying supported tags when the TestJob does not require the services
provided by devices with those tags will simply delay the running of
that TestJob by limiting the number of devices suitable for the job.
Please start changing any CI jobs *now* to prevent interruptions to
submissions. Removing tags will have no affect on submissions.
If in doubt, remove all tags from your JSON files.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Hello All,
I am able to successfully use the following boot_cmds option in Base model instances. However if I use the same on foundation model it does not work.
It comes to the uefi menu option and is not seem to issue any of my boot commands as defined in the json file.
Is it possible that for foundation models the boot_cmds option is not supported?
My json fragment is
"boot_cmds": [
"sendline 3",
"expect Choice:",
"sendline 2",
"expect Update entry:",
"sendline 1",
"expect File path of the EFI Application or the kernel: Image",
"sendline \n",
"expect Keep the initrd: [y/n]",
"sendline n",
"expect Arguments to pass to the binary: console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9",
"sendline \b9 root=/dev/vda2 rw",
"expect Description for this new Entry: Linux from SemiHosting",
"sendline \n",
"expect Choice:",
"sendline 5",
"expect Start:",
"sendline 1"
],
Any confirmation would be great!
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
Hi all,
I want to remind everyone that if you wish to communicate anything to do with the Lab in Cambridge, then you should always use the “lava-lab(a)linaro.xn--org-9o0a alias. The people on that list include the three of us in the LAVA team in Cambridge, as well as Alan and Tyler, so we cover a pretty wide time zone.
Additionally, just because you get a reply off one of us, please don’t cut the mailing list out of the loop. If one of us is unavailable, someone else can pick up the thread.
Many thanks
Dave
A gentle reminder !
From: Basil Eljuse
Sent: 09 February 2014 16:06
To: 'Linaro Validation'
Cc: Dean Arnold
Subject: Query on 5.3 Foundation model support in LAVA
Hi,
We were trying to get the latest published (5.3) foundation models in LAVA.
Using the reference as http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…
# The new (2013-10-03) Foundation model install places the simulator binary at Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8
21<http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…> # A symbolic link has been created in our arm_models-2013-10-03.tgz package to workaround this change for compatibilty sake. If you are getting an error
22<http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…> # chances are you are running a newer Foundation model and need to adjust this path.
23<http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…> simulator_command = sudo -u www-data /opt/arm/Foundation_v8pkg/Foundation_v8 --image={AXF} --block-device={IMG} --network=nat
Not quite sure what the comment refers to. However the key point for me is that rather than using the axf file I was hoping to define the boot options similar to what we have for the Base models.
The following is the typical boot options I wanted to use
<path-to>/Foundation_v8 \
--cores=4 \
--no-secure-memory \
--visualization \
--gicv3 \
--data="<path to bl1.bin>"@0x0 \
--data="<path to UEFI binary>"@0x8000000 \
--block-device="<path-to>/vexpress64-openembedded_lamp-armv8_20130927-7.img"
This would let me override the various argument like number of cores / --gicv3 or -no-gicv3 flag.
My understanding is that foundation models are quite cutdown version of Base models and hence does not have semihosting capabilitie etc, hence the uefi and blockdevice path should be relative to that of the foundation model location.
Question:: Can we use the boot options for foundation model the similar way it is used for base models? Is there an example for the same where we could cross-reference?
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
Hi,
I am trying to configure the lava dispatcher and execute on my local host.
with creating the image from
https://git.linaro.org/gitweb?p=lava/lava-vmdebootstrap.githttps://staging.validation.linaro.org/static/docs/kvm-deploy.html
by using kvm.json format with the actual location where I placed the image
after created,
# /tmp/kvm.json
{
"timeout": 18000,
"job_name": "kvm-test",
"device_type": "kvm",
"target": "kvm01",
"actions": [
{
"command": "deploy_linaro_image",
"parameters": {
"image": "file:///home/ubuntu/LAVA/lava-deployment-tool/kvm.img"
}
},
{
"command": "boot_linaro_image"
}
]
}
run the following command under root
. /srv/lava/instances/testinstances/bin/activate
lava-dispatch /tmp/kvm.json
it return the following error:
https://pastebin.linaro.org/view/bcbf8d01
any help will be much appreciated.
Thank You.
Best Regards
Soumya Basak.
Hi,
We were trying to get the latest puslished (5.3) foundation models in LAVA.
Using the reference as http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…
# The new (2013-10-03) Foundation model install places the simulator binary at Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8
21<http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…> # A symbolic link has been created in our arm_models-2013-10-03.tgz package to workaround this change for compatibilty sake. If you are getting an error
22<http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…> # chances are you are running a newer Foundation model and need to adjust this path.
23<http://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/d…> simulator_command = sudo -u www-data /opt/arm/Foundation_v8pkg/Foundation_v8 --image={AXF} --block-device={IMG} --network=nat
Not quite sure what the comment refers to. However the key point for me is that rather than using the axf file I was hoping to define the boot options similar to what we have for the Base models.
The following is the typical boot options I wanted to use
<path-to>/Foundation_v8 \
--cores=4 \
--no-secure-memory \
--visualization \
--gicv3 \
--data="<path to bl1.bin>"@0x0 \
--data="<path to UEFI binary>"@0x8000000 \
--block-device="<path-to>/vexpress64-openembedded_lamp-armv8_20130927-7.img"
This would let me override the various argument like number of cores / --gicv3 or -no-gicv3 flag.
My understanding is that foundation models are quite cutdown version of Base models and hence does not have semihosting capabilitie etc, hence the uefi and blockdevice path should be relative to that of the foundation model location.
Question:: Can we use the boot options for foundation model the similar way it is used for base models? Is there an example for the same where we could cross-reference?
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
