On 11 February 2016 at 18:20, Elster, Constantine
<celster(a)qti.qualcomm.com> wrote:
> Dear Neil / Linaro validation support team,
>
> Please see below our previous correspondence on configuring Dragonboard 410c
> with LAVA instance.
>
> Since then we migrated to the pipeline model and our goal at the moment is:
>
> 1. To have a well configured and responsive board with the LAVA
> pipeline instance
>
> 2. To have a simple test job that runs on our board + LOGS
>
> We see two options to achieve this:
>
> 1. By running:
>
> sudo lava-dispatch --target < device configuration YAML > < test-job YAML
>> --output-dir=/tmp/test/
Not recommended. You lose all the advantages of the scheduler, the
results handling, queries and charts as well as online access to the
logs, data export and history. However, this is part of the
development and debugging of the device configuration YAML. Just don't
stop at that point, it is a simple step to migrate that to a device
type template.Templates only start to look hard when the template is
optimised.
> 2. By defining the device dictionary
There is no template for this board either, at the moment, but that
isn't a problem.
https://validation.linaro.org/static/docs/pipeline-admin-example.html
This example works from a device working in the deprecated dispatcher
(which your board is, although the available config upstream is only
for android/fastboot, you have local config for the jobs you want to
run).
In order to have a device configuration YAML for #1, you are most of
the way to having a device-type template. For the template to be used
upstream, it would need to look more like the other templates to avoid
code duplication but a local template can (as the example above
mentions) be a simple YAML file without any templating support.
Equally, if you only have one board, then the device dictionary can be
minimal and the device type template will work fine as that bare YAML
file. (Effectively, every device of that type on that instance gets
exactly the same config.)
Don't let the jinja2 file extension put you off. It's just there for
syntax highlighting support in editors - the output of rendering the
template is YAML. It works in exactly the same way as django HTML
templates in web apps. Anything which jinja doesn't recognise as a
command, it outputs unchanged.
A device dictionary only needs to contain the 'extends', so if your
YAML template is called sbc8016e.jinja2 then the minimal device
dictionary would be:
{% extends 'sbc8016e.jinja2' %}
You only need to put more commands into the device dictionary if there
are more than one devices of this type on that one instance - then the
template uses {{ variable }} and the device dictionary uses {% set
variable = 'blah' %} where 'blah' differs from one device to the next.
> Would appreciate your support on the item #1:
>
> 1. We already have a deployed image on our board, we want to connect
> via SSH and run a simple (or sample) test job.
>
> a. how our device configuration YAML should look like?
A cut down version of this:
https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/lava_dispatcher/…
Cut down to something like this:
device_type: beaglebone-black
parameters:
none:
commands:
connect: telnet localhost 6000
actions:
deploy:
methods:
ssh:
options:
- '-o'
- 'Compression=yes'
- '-o'
- 'UserKnownHostsFile=/dev/null'
- '-o'
- 'PasswordAuthentication=no'
- '-o'
- 'StrictHostKeyChecking=no'
- '-o'
- 'LogLevel=FATAL'
- '-l'
- 'root '
- '-p'
- '22'
host: 172.16.200.165
identity_file: device/dynamic_vm_keys/lava
boot:
connections:
ssh:
methods:
ssh:
Don't rely on GMail not mangling the above - use
http://yaml-online-parser.appspot.com/?yaml=&type=json and make sure
it parses as valid YAML.
> b. how our test-job YAML (a simple pass/fail test, just to demonstrate
> it runs in the log files) should look like?
A working ssh-host job file for beaglebone-black is attached.
>
>
>
> Thank you,
>
> Alfred, Costi.
>
>
>
>
>
>
>
> -----Original Message-----
> From: Fradkin, Alex
> Sent: Thursday, February 04, 2016 12:38 AM
> To: Neil Williams
> Cc: nicolas.dechesne(a)linaro.org; Elster, Constantine; Ziskind, Alfred;
> Sedlak Grinbaum, Anna Hanna
> Subject: Re: Reproducing LAVA setup in Qualcomm lab - issues with
> Dragonboard410c device connection to LAVA
>
>
>
> Hi Neil,
>
>
>
> Thanks for detailed answer.
>
> We'll try to use new 2016.2 LAVA.
>
>
>
> Thanks,
>
> Alex
>
> ________________________________________
>
> From: Neil Williams <neil.williams(a)linaro.org>
>
> Sent: Tuesday, February 2, 2016 18:46
>
> To: Fradkin, Alex
>
> Cc: nicolas.dechesne(a)linaro.org; Elster, Constantine; Ziskind, Alfred;
> Sedlak Grinbaum, Anna Hanna
>
> Subject: Re: Reproducing LAVA setup in Qualcomm lab - issues with
> Dragonboard410c device connection to LAVA
>
>
>
> On 2 February 2016 at 13:20, Fradkin, Alex <alexf(a)qti.qualcomm.com> wrote:
>
>> Hi Neil/Niko,
>
>
>
> Please always use the mailing list support as I'm not always the best person
> to respond to all queries.
>
>
>
> https://validation.linaro.org/static/docs/support.html
>
>
>
> For this query, the linaro-validation mailing list is the best selection.
>
>
>
> https://lists.linaro.org/mailman/listinfo/linaro-validation
>
> linaro-validation(a)lists.linaro.org
>
>
>
>> We are trying to reproduce LAVA installation in our lab, but we have some
>> trouble with device connection to LAVA server.
>
>> Our device currently have preinstalled Debian or OpenEmbedded images and
>> we just want to execute tests on it (no need to create images at moment).
>
>
>
> Bear in mind that the new 2016.2 release moves the new pipeline dispatcher
> out of "developer mode" where it has been for over a year and into
> production. For devices like this, it is worth looking at that support too.
> This deprecates the old dispatcher (using JSON submissions and .conf files)
> but there is plenty of time - the old support will stay around for the
> majority of 2016.
>
>
>
> In general, it is much better to work with a device which is already working
> in another LAVA instance. The device configuration for devices hosted at the
> Cambridge LAVA lab is in https://git.linaro.org/lava/lava-lab.git.
>
>
>
>> Please see effort summary and details on what was done:
>
>> 1) LAVA server successfully installed on our Debian Jessie PC
>
>> (everything is installed on the same PC machine as explained in the
>
>> manual
>
>> https://validation.linaro.org/static/docs/installing_on_debian.html#in
>
>> stalling-the-full-lava-set )
>
>> 2) Created an administrator(superuser/Local Django Account), as
>
>> explained in the manual
>
>> https://validation.linaro.org/static/docs/installing_on_debian.html#lo
>
>> cal-django-account
>
>> 3) Device was attached to the same PC using serial interface, “cu” was
>
>> used to validate direct serial link connection with device (as
>
>> explained in manual
>
>> https://validation.linaro.org/static/docs/lava-image-creation.html#add
>
>> ing-a-device-to-lava )
>
>> 4) Device was added to LAVA dispatcher
>
>> a. Created a “sbc8016e.conf” in /etc/lava-dispatcher/devices:
>
>> Device_type = apq8016-sbc
>
>> Hostname = sbc8016e
>
>> Connection_command = sg dialout “cu –l /dev/ttyUSB0 –s
>> 115200”
>
>
>
> That connection command will only be used if the job involves a deploy and a
> boot. Persistent devices like dummy-ssh will not use the serial connection,
> just the SSH connection.
>
>
>
>> 5) Added a device to the scheduler with the same device type and name of
>> device as the hostname above. Please fined attached a screenshot “adding
>> device to scheduler”.
>
>> 6) Created a bundle stream. Please fined attached a screenshot “creating a
>> bundle stream”.
>
>>
>
>> We understood at this point that master image is required and in
>
>> normal case LAVA works with U-Boot based ARM devices and creates
>
>> special master boot-images and boot devices with it
>
>
>
> There is no need for a master image in your case. If the image is already
> deployed, then you would simply make the connection. In the old dispatcher,
> this would be a dummy-ssh device type, as long as an SSH server can be
> installed in the pre-built image. The device would not be powered off
> between jobs and there are issues with persistence.
>
>
>
> https://validation.linaro.org/static/docs/dispatcher-design.html#persistence
>
>
>
> It is also possible to "fake" a deploy and boot by passing boot arguments
> that load the filesystem kernel, dtb and possibly initramfs into memory and
> then boot those. Between tests, the device would then be powered off. In
> this method, you wouldn't use the SSH connection, the test would run over
> the serial connection, using auto-login support if required.
>
>
>
> In the pipeline dispatcher, this would be a primary connection using SSH or
> a uboot deployment.
>
>
>
> https://validation.linaro.org/static/docs/dispatcher-design.html#primary-co…
>
>
>
> In either case, what you need on the device is simply the bootloader and the
> image, with configuration to boot the image by default.
>
>
>
>> We also tried to connect LAVA to device using dummy-ssh connection as
>> described in
>> https://validation.linaro.org/static/docs/deprecated/dummy-deploy.html and
>> https://validation.linaro.org/static/docs/hacking-session.html :
>
>> 8) SSH hacking session - After that we tried to connect via an ssh as a
>> hacking session. As shown in the manual. Got same results.
>
>
>
> A hacking session is interactive - it expects to have an image deployed and
> booted, then to install something like openssh-server and then for a human
> to login and run commands.
>
>
>
>> 9) Deploying dummy devices – we changed the “sbc8016e.conf” file to a
>
>> dummy-SSH configuration as shown in the manual. Please fined attached
>
>> “sbc8016e.conf” file with dummy-SSH configuration
>
>> a) This is the only thing that gave us log entries (attached “dummy-ssh
>> log entries” screenshot). But it had no connection to our board, we got the
>> same logs with a disconnected board.
>
>
>
> I'm not sure what you mean by connection to your board. If you mean the boot
> logs, then you actually have to boot the device under the control of LAVA to
> get those - that means running a deploy and a boot.
>
> dummy-ssh expects the device to be permanently powered on, so it never logs
> anything about the boot. It will, however, log whatever happens over that
> SSH connection.
>
>
>
> The screenshot only indicates that you didn't specify a deploy action and
> that you are looking at the job summary. The Complete log button will show
> the full logs and there is also a download link. The one thing you didn't
> attach is the job definition, so I can't see why the job failed with
> "missing deploy action".
>
>
>
> The log files are much more useful than screenshots, generally.
>
>
>
>> Could you please help with us with device<->Lava connection setup?
>
>> We have device with preinstalled Debian or OpenEmbedded images, as
>
>> mentioned before and we just want to execute test (so we need to skip
>> deploy and boot part of the job) if you have please provide detailed "howto"
>> for device setup:
>
>> - what need to be installed on device
>
>> - how to configure device and server for network (SSH?) or serial port
>
>> connection
>
>>
>
>> Could you please also provide links to real yaml test jobs you have
>
>> for
>
>> - functionality validation (storage/network/USB/display/cameras/...)
>
>
>
>> - performance validation (jobs that execute benchmarks)
>
>> - stability tests
>
>
>
> The majority of git.linaro.org consists of real yaml test jobs but to get a
> specific answer about which ones are current and useful for your own work,
> you need to get input from the QA team at Linaro. The linaro-validation
> mailing list is one way to do that. I would suggest starting a separate
> thread for this question.
>
>
>
> --
>
>
>
> Neil Williams
>
> =============
>
> neil.williams(a)linaro.org
>
> http://www.linux.codehelp.co.uk/
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
The 2016.2 release marks the start of the migration to the pipeline
dispatcher. The previous dispatcher code, the documentation for that
code and the support for JSON job formats are now *deprecated*. As a
result, the corresponding lava-server code has also been *deprecated*,
this includes Bundles, Filters and Image Reports (original and 2.0).
The deprecated Dashboard is replaced by Results with Queries and
Charts which have been ported to the data produced by the pipeline
testjobs.
Future development within LAVA will be based solely on the pipeline
dispatcher and associated server side objects. Support for the
deprecated dispatcher will be maintained for future releases only
during the migration and *will be removed* once the migration is
complete. The migration is expected to take most of 2016. Individual
devices and particular items of job support will be gradually disabled
until the migration completes for all devices and all jobs.
The migration process involves:
0: Adding pipeline support for devices and deployment methods
1: Migrating user submissions and automated submissions to the
pipeline support. For the Linaro LAVA instances, this will happen
within the particular teams inside Linaro.
2: Making selected devices exclusive to the pipeline so that JSON jobs
can no longer be submitted for those devices. At this point, support
for JSON jobs which rely on those devices will cease.
3: Once all devices are exclusive, reject all JSON submissions.
4: Disable the old scheduler daemon on the LAVA instance.
At some point, probably in 2017 - a month or two after JSON
submissions cease - the migration will complete by executing:
5: Removal of code support for the old dispatcher in lava-dispatcher
and lava-tool codebases and associated documentation.
6: Removal of code support for database objects specific to the old
dispatcher, like Bundle, in lava-server with associated documentation.
This will involve the deletion of the Bundle data as well as image
reports, filters and BundleStreams. TestJob objects which are not
pipeline jobs will also be deleted.
7: Removal of the rest of the code which is still dependent upon or
only used to support deprecated objects and functions.
8: Modification of code which only exists to isolate the deprecated
objects from the pipeline objects. e.g. newly created jobs or devices
will default to pipeline support.
LAVA instances outside Linaro will need to manage their own migrations
during 2016 if updates are to be applied during 2017.
It is not possible to retain the database objects without the
deprecated code, so owners of individual instances may choose to
create an archive instance which has no online devices, accepts no
submissions, just provides access to a snapshot of the data at the
time that JSON submissions ceased. To maintain access to the archived
data, this instance must not upgrade to LAVA releases after the
archive is created and the original devices should persist in the
database but be kept in the Offline state. Devices should also have
submissions restricted to a single administrator account for which no
API token exists.
More information on the details of the migration and the state of
support for jobs using the old dispatcher will be announced on this
mailing list.
As a reminder - lava-announce is a read-only list. Posts to this list
are only made by the LAVA software team. Replies need to be directed
to
linaro-validation(a)lists.linaro.org - your email client should do this
for you, using the Reply-To header added by mailman.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi,
I would like to use lava for coreboot.
coreboot is an open-source bootloader for multiple architectures
including replacing BIOS/UEFI on x86.
coreboot needs to installed on flash which is soldered on the mainboard.
To flash/install coreboot you need an external SPI flasher e.g. the
Beagleboneblack can do this. Using a SPI Testclip, it's possible to
flash the SPI chip in-circuit. The SPI chip and partially the mainboard
needs to be powered externally.
My concrete test setup is a thinkpad x60.
To flash coreboot, I have to do the following:
1 disconnect the power to DUT
2 connect external 3.3V to the SPI chip (and partially DUT)
3 connect the beagleboneblack's SPI pins to the DUT
4 flash coreboot via beagleboneblack
5 disconnect beagleboneblack
6 disconnect external power supply
7 power the x60
8 press the power button of the DUT
9 run test on linux
I've managed to do all the hardware work.
* control the power to the DUT via pdudaemon using a ubiquity power [1].
* control external 3.3V via raspberry gpio's on a relais card
* control powerbutton via raspberry gpio's on a relais card
* put beagleboneblack's spi pins into high-z via dts-overlays [2]
TLDR;
I'm looking for feedback about implementing a lava for coreboot.
What's a good way to integrate the coreboot flashing flow into lava?
I started writing a pipeline driver for flashrom [3].
How should I integrate the raspberrypi's gpios controlling important
things? Using pdudaemon again?
Do you use safeguards to protect damage from devices?
E.g. It's possible to enable both powersupply for DUT and might kill one.
[1] https://github.com/mattface/pdudaemon/pull/1
[2] https://github.com/lynxis/bbb_highz_spi
[3] https://github.com/lynxis/lava-dispatcher/blob/master/lava_dispatcher/pipel…
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
