From: Biju Das <biju.das@...>

The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).
To increase hardware support enable the driver in the
multi_v7_defconfig multiplatform configuration.

Signed-off-by: Biju Das <biju.das@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 545dc83ed09b5c04f663b766a92cbc8bb02c5f15)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index f1ba3fb..ba520f6 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -607,6 +607,7 @@ CONFIG_RTC_DRV_MAX77686=y
CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_MAX77802=m
CONFIG_RTC_DRV_RS5C372=m
+CONFIG_RTC_DRV_BQ32K=m
CONFIG_RTC_DRV_PALMAS=y
CONFIG_RTC_DRV_ST_LPC=y
CONFIG_RTC_DRV_TWL4030=y
--
2.7.4

From: Biju Das <biju.das@...>

The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).
To increase hardware support enable the driver in the
shmobile_defconfig multiplatform configuration.

Signed-off-by: Biju Das <biju.das@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 0736aad1290d61bc3668f20253e1e1997ad8b3c1)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index e8a2d0b..2e79332 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -178,6 +178,7 @@ CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_BQ32K=y
CONFIG_RTC_DRV_S35390A=y
CONFIG_RTC_DRV_RX8581=y
CONFIG_DMADEVICES=y
--
2.7.4

From: Biju Das <biju.das@...>

Define the iWave RainboW-G20D-Qseven board dependent part of the
RTC device node.

Signed-off-by: Biju Das <biju.das@...>
Signed-off-by: Chris Paterson <chris.paterson2@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit e0e63658c2f291e0672fdf96df1f9f2963a6a9f6)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index 081af01..f3b4890 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -22,6 +22,11 @@
};

&pfc {
+ i2c2_pins: i2c2 {
+ groups = "i2c2";
+ function = "i2c2";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
@@ -54,3 +59,16 @@
micrel,led-mode = <1>;
};
};
+
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ rtc@68 {
+ compatible = "bq32000";
+ reg = <0x68>;
+ };
+};
--
2.7.4

This patch series aims at adding RTC support to the iwg20d
board from iWave.
The commits from this series backport board specific DT
support and defconfig support.

Biju Das (3):
ARM: dts: iwg20d-q7: Add RTC support
ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig
ARM: multi_v7_defconfig: Enable BQ32000 RTC driver

arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 18 ++++++++++++++++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/shmobile_defconfig | 1 +
3 files changed, 20 insertions(+)

--
2.7.4

Hi,

this is a summary of the CIP related work we've done the last couple of weeks:

## Kernel maintenance

* Reviewed patches from Renesas to add support for SMP and I²C masters
on R8A7743 SoC, and applied them to the CIP kernel branch

* Reviewed Robert's merge request for B@D

* Discussed opportunities for CIP member participation at DebConf

* Reviewed the changes in stable release 4.4.113 (but didn't yet merge
them)

## CIP testing

* Went through the open tickets and sent to backlog all those that are related
with B@D development.
** Confirmed #157 is still an issue: https://gitlab.com/cip-project/cip-testing/testing/issues/157
** Unable to replicate #170 so far: https://gitlab.com/cip-project/cip-testing/testing/issues/170

* Working on #173 opened by Zoran: https://gitlab.com/cip-project/cip-testing/
testing/issues/173

* B@D working with new kernelci version. Consolidation required.
** Latest kernel tested and report by e-mail sent to mailing list.

* Relaxed permissions in /etc/linaro to adapt them to B@D use case #165:
https://gitlab.com/cip-project/cip-testing/testing/issues/165

* Busybox updated to a newer version.

## Others

* Updated milestones in the CIP testing project to adapt them to the new
maintenance mode.

* Although our participation was approved, in the last minute a collision in
my schedule prevent me from attending to OpenExpo in Madrid. No one else can
so I communicated to the organization we cannot attend.

* Open question: should we send Gitlab notifications to the mailing list?

As usual you can fin more accurate info about our work by reading the journal:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/
journal

Best Regards
--
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd

More about proxies:

Here is update on the Lava proxy business. Please, read this very
carefully, since this is the solution to the problems with Lava
proxies, as well as Lava DUT ones.

YES, after applying what Remi advised to me, the qemu01 test:
https://www.validation.linaro.org/static/docs/v2/first-job.html

worked like a charm. I simply copied /etc/lava-server/env.yaml to
/etc/lava-server/env.dut.yaml (and created the new file).

Remi, I would like to thank you for the advise!

Best Regards,
Zoran Stojsavljevic

---------- Forwarded message ----------
From: Remi Duraffort <remi.duraffort@...>
Date: Thu, Feb 15, 2018 at 4:30 PM
Subject: Re: [Lava-users] [HW target questions] Pointers from Lava
test suite to the HW target
To: Zoran S <zoran.stojsavljevic.de@...>
Cc: Lava Users Mailman list <lava-users@...>


Not exactly.

1/ The process that is deploying, booting and testing a DUT (Device
Under test) is called lava-run.
lava-run environment variables are controlled by /etc/lava-server/env.yaml

By default, all environment variables are removed and only a small set
of variables are added.
This helps to make executions reproducible between dispatchers and instances.

So if you need an environment variable to be set, then you have to add
it to /etc/lava-server/env.yaml

2/ On the DUT itself, by default, we don't add or change any
environment variable. Because that's the user responsibility.
However, if /etc/lava-server/env.dut.yaml does exists, it will be used
to add environment variables to the DUT shell.
To create the list of environment variables to add to the DUT, we take
the full environment from lava-run (as defined by
/etc/lava-server/env.yaml) and we apply the rules from env.dut.yaml.

I hope that does help you to understand how environment is setup in lava.

Rgds

On Wed, Feb 14, 2018 at 2:04 PM, Zoran S
<zoran.stojsavljevic.de@...> wrote:

https://gitlab.com/cip-project/cip-testing/testing/issues/99

Also from:
https://lists.cip-project.org/pipermail/cip-dev/2017-July/000338.html

At the end of test issue #99, I added the solution to this problem.

Lava does NOT read VM's ENV variables. It ignores them. Lava reads
/etc/lava-server/env.yaml as setup proxy file!

Included there also /etc/lava-server/env.yaml file example.

It could be done also DIRECTLY (every time bringing up the VM) using
python, tapping into the urllib3 python code (example given):
https://stackoverflow.com/questions/31151615/how-to-handle-proxies-in-urllib3

I've tried this, using in-line python interpreter, it worked.

Zoran

On Tue, 2018-01-16 at 08:01 +0000, Chris Paterson wrote:
[...]

Meltdown:
- arm 32-bit: Not affected?  (ARM reports that only the Cortex-A75 is
  affected, but I haven't seen information from other architecture
  licensees.)

ARM also lists that meltdown subvariant '3a' affects some arm 32-bit
processors [1], but say that "In general, it is not believed that
software mitigations for this issue are necessary".

The whitepaper ARM link to [2] implies that ARM don't think this is
an issue worth worrying about as the information that can be obtained
from the system registers is "not material".

Have you heard/seen anything to contradict this statement?

No I haven't.

[...]

Will you be keeping an eye on Spectre patches on behalf of CIP as
part of your maintainer role? I guess you may be in the loop a bit
more than the rest of us?

I will look at the mitigations as they land upstream, but I still think
these are low priority security issues for CIP.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.

https://gitlab.com/cip-project/cip-testing/testing/issues/99

Also from:
https://lists.cip-project.org/pipermail/cip-dev/2017-July/000338.html

At the end of test issue #99, I added the solution to this problem.

Lava does NOT read VM's ENV variables. It ignores them. Lava reads
/etc/lava-server/env.yaml as setup proxy file!

Included there also /etc/lava-server/env.yaml file example.

It could be done also DIRECTLY (every time bringing up the VM) using
python, tapping into the urllib3 python code (example given):
https://stackoverflow.com/questions/31151615/how-to-handle-proxies-in-urllib3

I've tried this, using in-line python interpreter, it worked.

Zoran

Hi Zoran

Zoran S <zoran.stojsavljevic.de@...> writes:

the current version of B@D uses YAML submissions - see the files in the
tests subdirectory.

Could you, please, point to me where these test directories are?

https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/tree/master/tests

I did build two vagrant VM machines, one with debian/stratch64, second
pre-built debian9, which refuses to behave correctly.

In other words, I would like to see if these test directories are also
in debian/stretch, built from scratch. If yes, I can go from it to
build/configure the BBB one.

And if you're building the VMs using the B@D git repos on the VM they'll
be in /vagrant/tests

Since I need to reconfigure the Lava environment to use Beagle Bone Black.

I'm assuming the 'we' refers to your usage of LAVA as B@D doesn't use V1 tests.
I'd recommend moving to V2!

If you do it with YAML, this is V2, so this answers it all.

Robert
--
I'm now only responding to B@D/CIP issues on 3 days a week - normally
Wednesday-Friday, on other days emails to cip-dev or directly to me are
likely to be seen, but unlikely to be responded to, until a day I'm
attending to B@D.

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 4:21 PM, Robert Marshall
<robert.marshall@...> wrote:

Zoran,

Zoran S <zoran.stojsavljevic.de@...> writes:

Hello Robert,

You are correct. I am (as I email to the list about V2) finding more
info about the Lava framework.

The fact is that, since Lava 2017.2 Version 2 is first usable version
along with Version 1. Both versions coexist from Lava 2017.2 till Lava
2017.9.

According to the B@D feature page, 0.9.1 was using 2016.12-1 and that was
V2 - the tests were yaml files then.

Lava 2017.9 was the last one to have both versions (and
Version 1 latest and greatest release). From Lava 2017.11 there is
ONLY one version in it: Version 2. Now, every months Linaro releases
new Lava version, and currently they are at 2018.2.

So, Lava 2017.7 (used for by CIP testing now) is both V1 and V2 compliant.

There is a significant difference between Version 1 and Version 2,
considering test scripts: V1 uses JSON test job submissions, V2 uses
YAML test job submissions.

the current version of B@D uses YAML submissions - see the files in the
tests subdirectory.

So, here I made a mistake. I was under impression that the test script
format did not change, transiting from V1 to V2. Eeeeeeeek. Wrong!

The call here is: to use Version 1 or Version 2 from now on, that is
the question? And if we continue to use V1, for how long?

I'm assuming the 'we' refers to your usage of LAVA as B@D doesn't use V1 tests.
I'd recommend moving to V2!

Robert

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 3:29 PM, Robert Marshall
<robert.marshall@...> wrote:

Zoran


"zoran.stojsavljevic.de" <zoran.stojsavljevic.de@...> writes:

Hello Robert,

As I am continuing to investigate this issue with the testing
framework, apparently Linaro does NOT support anymore Lava V1
(decisively), they already switched to Lava V2 (please, see forwarded
email from Neil Williams).

As my understanding is, they introduced Lava V2 in 2017.11 version. So
far, they've deleted all the databases with the Lava V1 test results
(I guess, this applies for Linaro environment usage).

We've been using LAVA v 2 from the start (well at least from the 0.9
release and maybe earlier). We're still using LAVA 2017-7

https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage

gives the relevant versions.

I am forced to switch abruptly to Lava V2, and here is what I assume
after 2 day investigation (yesterday and ongoing today) on Lava:
[1] The Lava Version 1 (as well as CIP RT kernel) testing scripts did
not change at all;
[2] The Lava Version 2 setup did change, in the sense that there are
some new technologies used (jinja2 U-Boot parsers);
[3] The communication architecture between lava-server and lava-worker
did change (ZMQ and XML-RPC), but this is hidden beneath/under the
hood (does not affect anything on testing level, Linaro claims this
way of the communication between Master and Worker is faster)...

Seems an easy change to go, but knowing these humongous Python
frameworks (YOCTO Project as obvious example), nothing is easy these
days.

Does anybody work on Lava Version 2 these days? Would be interesting
to try the whole CIP testing framework I am trying to bring up with
Lava Version 2.

I'm not sure what you mean here as V2 is under active development?

Any opinions/provisos on this topic?

(please, do note that I have changed my email address on CIP mailing
list, introducing the third [more convenient] gmail email for others).

Thank you,
Zoran Stojsavljevic

---------- Forwarded message ----------
From: Zoran S <zoran.stojsavljevic.de@...>
Date: Fri, Feb 9, 2018 at 2:01 PM
Subject: Re: [Lava-users] [HW target questions] Pointers from Lava
test suite to the HW target
To: Neil Williams <neil.williams@...>
Cc: Lava Users Mailman list <lava-users@...>


Hello Neil,

Please, hold your horses. I am very new to all this, and I need some
time to get to the Lava architecture, meaning to get in proper ways.
In the sense, I'll try to rephrase the questions, and the working
context, since your answers make me more confused than bring the
viable solutions... :-(

After reading your email, there are the major addendums to this
context, so let me rephrase/rework my initial email.
_______

My aim is to use Lava V2 (since Lava V1 is not supported anymore). Let it be.

As I mentioned, I would like to use Beagle Bone Black (BBB) to Lava
worker, and from Lava apache to set the proper context for testing BBB
HW.

But also, for the starters (seems the step in between) I can do QEMU
(the problem is I have no idea how to do this outside of YOCTO
Project).

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

I am running Lava v2017/7. Which supports ONLY V1. On Virtual Machine
Debian Stretch (using VBox as VMM).

root@stretch:/home/vagrant# uname -a
Linux stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
root@stretch:/home/vagrant# dpkg-query -W -f '${version}\n' 'lava-server'
2017.07

My problem here is that I can build the newest version of the
Hashicorp debian/stretch64 using vagrant:
https://app.vagrantup.com/debian/boxes/stretch64

But I am NOT able to include the newest Lava into this setup, since
apt-get install Lava (and components) is bringing me Lava V1 (even
very old version 2016.12-2)???

Q1: how I can bring here the newest Lava 2018.01 (only Version 2
compliant)? What the apt-get install Lava-2018.01 or similar command
(I am Fedora monkey, as considering my host setup. Lava I am
bringing/installing into the VM over VBox VMM)?

In other words, what is the specific command I need to use in scripts
to bring proper Lava 2018.01??? Or any another command?
Here is what is now used: sudo DEBIAN_FRONTEND=noninteractive apt-get
-y install lava -t stretch-backports

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

I already use the newest 2017.11 BBB U-Boot, so anyway I need to tap
(and change some strings) into the following files (as of my best
understanding):
root@stretch:/# find . -name base-uboot.jinja2
./etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
root@stretch:/# find . -name beaglebone-black.jinja2
./etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
root@stretch:/# find . -name qemu.jinja2
./etc/lava-server/dispatcher-config/device-types/qemu.jinja2
root@stretch:/#

Q2: I need here some examples, if they exist. How I can build these
scripts, or should I use existing? Or to do something more to hook
Lava to ser2net?

I already know: interrupt_prompt: {{ interrupt_prompt|default('Hit any
key to stop autoboot') }} <<===== String MUST be changed for U-Boot
2017.11!

Q3: I see that base-uboot.jinja2 is a base file. Should I include it
it other .jinja2 files using:
{% extends 'base-uboot.jinja2' %}

That looks like you have to manage the power control using
a graphical interface and that's not going to work...

Let us skip for now this question (I would like to simplify). PDU is
for now not of importance. Focusing to make minimalistic approach to
work.

That will show up in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

The whole ttyUSB0 using ser2net TCP is done already, works like a
charm. In VM, as pass-through device.

Q4: do I need to use something special here to hook ser2net terminal to Lava?

root@stretch:/# cd /dev/serial
root@stretch:/dev/serial# ls -al
total 0
drwxr-xr-x 4 root root 80 Feb 9 11:29 .
drwxr-xr-x 19 root root 3140 Feb 9 11:32 ..
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-id
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-path
root@stretch:/dev/serial#

That is all managed by LAVA in the test job submission. TFTP is already configured.

in.tftp works like a charm (tftp-ing from VM to U-Boot BBB), as well
as dhcpd (dnsmasq, also from VM). So, I have to trust you if you say
that I do not need to do anything on that.

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

In fact, this was not my question (I have latest 2017.11 U-Boot there
on mmcblk1 which is /boot partition, works perfectly).

Q5: I wanted to know do I need to set up U-Boot scripts in some ways
(as /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
suggests, as example)??? In other words, make U-Boot environment more
as .jinja2 suggests?

Start with QEMU, make sure that's working and get an understanding
of how that works with the device dictionary, test job submission,
test shell definitions and general LAVA UI usage.

Q6: So, what I need to do here? I use YOCTO project to build all BBB
embedded Linux ingredients, uImage, .dtb and root tree, how I can use
QEMU from YOCTO as independent .exe in Lava context??? Or, maybe,
after all, I can try real image?!

I apologize for the long email. Some features are already solved
(tftp, edhcp, ser2net), so we do not need to include them further (as
I now understand).

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 10:23 AM, Neil Williams <neil.williams@...> wrote:

On 9 February 2018 at 09:00, Zoran S <zoran.stojsavljevic.de@...>
wrote:

Hello to the Lava users,

I am the new Lava user. My aim is to use Lava (for now V1)

Welcome. Please take care with terminology. V1 is already dead, please don't
start there. We will be unable to help you with your V1 setup. Your later
comments refer to elements from V2, so please take care with which bits of
documentation you are following.

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

setup for my testing, from the beginning just to hook-up my Beagle Bone
Black (BBB) to Lava worker, and from Lava apache to set the proper context
for testing BBB HW.

As I am reading Lava framework, I got the following impression about the
test suite:
[1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup;

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

[2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and
POFF HW platform);

That looks like you have to manage the power control using a graphical
interface and that's not going to work. You'll need to investigate how to
control that unit using the command line only. Does it have a telnet API or
other serial API? That will all be down to you to configure. You might want
to look at using an APC PDU instead as those already have support in lavapdu
(or can use SNMP if you configure the worker appropriately).

[3] I need to hook-up ser2net interface (which I already have working over
TCP) to the Lava. so Lava can control it;

That goes into the device dictionary, as per the docs. Do you have the FTDI
cable to attach to the BBB to get the serial connection? That will show up
in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

[4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which
will be FTPed and set in memory for board setup and testing).

TFTP, not FTP.

That is all managed by LAVA in the test job submission. TFTP is already
configured.

Question 1: Does manual have some Beagle Bone Black U-Boot default
scripts, which should be provisioned to the BBB U-Boot for the correct Lava
U-Boot behavior?

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some
explanation as working example how to do these points?

Those are mostly specific to your local setup.

Question 3: Anything else I missed for the proper Lava test setting?

Start with QEMU, make sure that's working and get an understanding of how
that works with the device dictionary, test job submission, test shell
definitions and general LAVA UI usage.

Thank you in advance,
Zoran

_____________________________________________

Lava-users mailing list
Lava-users@...
https://lists.linaro.org/mailman/listinfo/lava-users

Neil Williams
=============
neil.williams@...
http://www.linux.codehelp.co.uk/

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

the current version of B@D uses YAML submissions - see the files in the
tests subdirectory.

Could you, please, point to me where these test directories are?

I did build two vagrant VM machines, one with debian/stratch64, second
pre-built debian9, which refuses to behave correctly.

In other words, I would like to see if these test directories are also
in debian/stretch, built from scratch. If yes, I can go from it to
build/configure the BBB one.

Since I need to reconfigure the Lava environment to use Beagle Bone Black.

I'm assuming the 'we' refers to your usage of LAVA as B@D doesn't use V1 tests.
I'd recommend moving to V2!

If you do it with YAML, this is V2, so this answers it all.

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 4:21 PM, Robert Marshall
<robert.marshall@...> wrote:

Zoran,

Zoran S <zoran.stojsavljevic.de@...> writes:

Hello Robert,

You are correct. I am (as I email to the list about V2) finding more
info about the Lava framework.

The fact is that, since Lava 2017.2 Version 2 is first usable version
along with Version 1. Both versions coexist from Lava 2017.2 till Lava
2017.9.

According to the B@D feature page, 0.9.1 was using 2016.12-1 and that was
V2 - the tests were yaml files then.

Lava 2017.9 was the last one to have both versions (and
Version 1 latest and greatest release). From Lava 2017.11 there is
ONLY one version in it: Version 2. Now, every months Linaro releases
new Lava version, and currently they are at 2018.2.

So, Lava 2017.7 (used for by CIP testing now) is both V1 and V2 compliant.

There is a significant difference between Version 1 and Version 2,
considering test scripts: V1 uses JSON test job submissions, V2 uses
YAML test job submissions.

the current version of B@D uses YAML submissions - see the files in the
tests subdirectory.

So, here I made a mistake. I was under impression that the test script
format did not change, transiting from V1 to V2. Eeeeeeeek. Wrong!

The call here is: to use Version 1 or Version 2 from now on, that is
the question? And if we continue to use V1, for how long?

I'm assuming the 'we' refers to your usage of LAVA as B@D doesn't use V1 tests.
I'd recommend moving to V2!

Robert

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 3:29 PM, Robert Marshall
<robert.marshall@...> wrote:

Zoran


"zoran.stojsavljevic.de" <zoran.stojsavljevic.de@...> writes:

Hello Robert,

As I am continuing to investigate this issue with the testing
framework, apparently Linaro does NOT support anymore Lava V1
(decisively), they already switched to Lava V2 (please, see forwarded
email from Neil Williams).

As my understanding is, they introduced Lava V2 in 2017.11 version. So
far, they've deleted all the databases with the Lava V1 test results
(I guess, this applies for Linaro environment usage).

We've been using LAVA v 2 from the start (well at least from the 0.9
release and maybe earlier). We're still using LAVA 2017-7

https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage

gives the relevant versions.

I am forced to switch abruptly to Lava V2, and here is what I assume
after 2 day investigation (yesterday and ongoing today) on Lava:
[1] The Lava Version 1 (as well as CIP RT kernel) testing scripts did
not change at all;
[2] The Lava Version 2 setup did change, in the sense that there are
some new technologies used (jinja2 U-Boot parsers);
[3] The communication architecture between lava-server and lava-worker
did change (ZMQ and XML-RPC), but this is hidden beneath/under the
hood (does not affect anything on testing level, Linaro claims this
way of the communication between Master and Worker is faster)...

Seems an easy change to go, but knowing these humongous Python
frameworks (YOCTO Project as obvious example), nothing is easy these
days.

Does anybody work on Lava Version 2 these days? Would be interesting
to try the whole CIP testing framework I am trying to bring up with
Lava Version 2.

I'm not sure what you mean here as V2 is under active development?

Any opinions/provisos on this topic?

(please, do note that I have changed my email address on CIP mailing
list, introducing the third [more convenient] gmail email for others).

Thank you,
Zoran Stojsavljevic

---------- Forwarded message ----------
From: Zoran S <zoran.stojsavljevic.de@...>
Date: Fri, Feb 9, 2018 at 2:01 PM
Subject: Re: [Lava-users] [HW target questions] Pointers from Lava
test suite to the HW target
To: Neil Williams <neil.williams@...>
Cc: Lava Users Mailman list <lava-users@...>


Hello Neil,

Please, hold your horses. I am very new to all this, and I need some
time to get to the Lava architecture, meaning to get in proper ways.
In the sense, I'll try to rephrase the questions, and the working
context, since your answers make me more confused than bring the
viable solutions... :-(

After reading your email, there are the major addendums to this
context, so let me rephrase/rework my initial email.
_______

My aim is to use Lava V2 (since Lava V1 is not supported anymore). Let it be.

As I mentioned, I would like to use Beagle Bone Black (BBB) to Lava
worker, and from Lava apache to set the proper context for testing BBB
HW.

But also, for the starters (seems the step in between) I can do QEMU
(the problem is I have no idea how to do this outside of YOCTO
Project).

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

I am running Lava v2017/7. Which supports ONLY V1. On Virtual Machine
Debian Stretch (using VBox as VMM).

root@stretch:/home/vagrant# uname -a
Linux stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
root@stretch:/home/vagrant# dpkg-query -W -f '${version}\n' 'lava-server'
2017.07

My problem here is that I can build the newest version of the
Hashicorp debian/stretch64 using vagrant:
https://app.vagrantup.com/debian/boxes/stretch64

But I am NOT able to include the newest Lava into this setup, since
apt-get install Lava (and components) is bringing me Lava V1 (even
very old version 2016.12-2)???

Q1: how I can bring here the newest Lava 2018.01 (only Version 2
compliant)? What the apt-get install Lava-2018.01 or similar command
(I am Fedora monkey, as considering my host setup. Lava I am
bringing/installing into the VM over VBox VMM)?

In other words, what is the specific command I need to use in scripts
to bring proper Lava 2018.01??? Or any another command?
Here is what is now used: sudo DEBIAN_FRONTEND=noninteractive apt-get
-y install lava -t stretch-backports

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

I already use the newest 2017.11 BBB U-Boot, so anyway I need to tap
(and change some strings) into the following files (as of my best
understanding):
root@stretch:/# find . -name base-uboot.jinja2
./etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
root@stretch:/# find . -name beaglebone-black.jinja2
./etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
root@stretch:/# find . -name qemu.jinja2
./etc/lava-server/dispatcher-config/device-types/qemu.jinja2
root@stretch:/#

Q2: I need here some examples, if they exist. How I can build these
scripts, or should I use existing? Or to do something more to hook
Lava to ser2net?

I already know: interrupt_prompt: {{ interrupt_prompt|default('Hit any
key to stop autoboot') }} <<===== String MUST be changed for U-Boot
2017.11!

Q3: I see that base-uboot.jinja2 is a base file. Should I include it
it other .jinja2 files using:
{% extends 'base-uboot.jinja2' %}

That looks like you have to manage the power control using
a graphical interface and that's not going to work...

Let us skip for now this question (I would like to simplify). PDU is
for now not of importance. Focusing to make minimalistic approach to
work.

That will show up in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

The whole ttyUSB0 using ser2net TCP is done already, works like a
charm. In VM, as pass-through device.

Q4: do I need to use something special here to hook ser2net terminal to Lava?

root@stretch:/# cd /dev/serial
root@stretch:/dev/serial# ls -al
total 0
drwxr-xr-x 4 root root 80 Feb 9 11:29 .
drwxr-xr-x 19 root root 3140 Feb 9 11:32 ..
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-id
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-path
root@stretch:/dev/serial#

That is all managed by LAVA in the test job submission. TFTP is already configured.

in.tftp works like a charm (tftp-ing from VM to U-Boot BBB), as well
as dhcpd (dnsmasq, also from VM). So, I have to trust you if you say
that I do not need to do anything on that.

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

In fact, this was not my question (I have latest 2017.11 U-Boot there
on mmcblk1 which is /boot partition, works perfectly).

Q5: I wanted to know do I need to set up U-Boot scripts in some ways
(as /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
suggests, as example)??? In other words, make U-Boot environment more
as .jinja2 suggests?

Start with QEMU, make sure that's working and get an understanding
of how that works with the device dictionary, test job submission,
test shell definitions and general LAVA UI usage.

Q6: So, what I need to do here? I use YOCTO project to build all BBB
embedded Linux ingredients, uImage, .dtb and root tree, how I can use
QEMU from YOCTO as independent .exe in Lava context??? Or, maybe,
after all, I can try real image?!

I apologize for the long email. Some features are already solved
(tftp, edhcp, ser2net), so we do not need to include them further (as
I now understand).

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 10:23 AM, Neil Williams <neil.williams@...> wrote:

On 9 February 2018 at 09:00, Zoran S <zoran.stojsavljevic.de@...>
wrote:

Hello to the Lava users,

I am the new Lava user. My aim is to use Lava (for now V1)

Welcome. Please take care with terminology. V1 is already dead, please don't
start there. We will be unable to help you with your V1 setup. Your later
comments refer to elements from V2, so please take care with which bits of
documentation you are following.

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

setup for my testing, from the beginning just to hook-up my Beagle Bone
Black (BBB) to Lava worker, and from Lava apache to set the proper context
for testing BBB HW.

As I am reading Lava framework, I got the following impression about the
test suite:
[1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup;

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

[2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and
POFF HW platform);

That looks like you have to manage the power control using a graphical
interface and that's not going to work. You'll need to investigate how to
control that unit using the command line only. Does it have a telnet API or
other serial API? That will all be down to you to configure. You might want
to look at using an APC PDU instead as those already have support in lavapdu
(or can use SNMP if you configure the worker appropriately).

[3] I need to hook-up ser2net interface (which I already have working over
TCP) to the Lava. so Lava can control it;

That goes into the device dictionary, as per the docs. Do you have the FTDI
cable to attach to the BBB to get the serial connection? That will show up
in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

[4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which
will be FTPed and set in memory for board setup and testing).

TFTP, not FTP.

That is all managed by LAVA in the test job submission. TFTP is already
configured.

Question 1: Does manual have some Beagle Bone Black U-Boot default
scripts, which should be provisioned to the BBB U-Boot for the correct Lava
U-Boot behavior?

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some
explanation as working example how to do these points?

Those are mostly specific to your local setup.

Question 3: Anything else I missed for the proper Lava test setting?

Start with QEMU, make sure that's working and get an understanding of how
that works with the device dictionary, test job submission, test shell
definitions and general LAVA UI usage.

Thank you in advance,
Zoran

_____________________________________________

Lava-users mailing list
Lava-users@...
https://lists.linaro.org/mailman/listinfo/lava-users

Neil Williams
=============
neil.williams@...
http://www.linux.codehelp.co.uk/

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

Zoran,

Zoran S <zoran.stojsavljevic.de@...> writes:

Hello Robert,

You are correct. I am (as I email to the list about V2) finding more
info about the Lava framework.

The fact is that, since Lava 2017.2 Version 2 is first usable version
along with Version 1. Both versions coexist from Lava 2017.2 till Lava
2017.9.

According to the B@D feature page, 0.9.1 was using 2016.12-1 and that was
V2 - the tests were yaml files then.

Lava 2017.9 was the last one to have both versions (and
Version 1 latest and greatest release). From Lava 2017.11 there is
ONLY one version in it: Version 2. Now, every months Linaro releases
new Lava version, and currently they are at 2018.2.

So, Lava 2017.7 (used for by CIP testing now) is both V1 and V2 compliant.

There is a significant difference between Version 1 and Version 2,
considering test scripts: V1 uses JSON test job submissions, V2 uses
YAML test job submissions.

the current version of B@D uses YAML submissions - see the files in the
tests subdirectory.

So, here I made a mistake. I was under impression that the test script
format did not change, transiting from V1 to V2. Eeeeeeeek. Wrong!

The call here is: to use Version 1 or Version 2 from now on, that is
the question? And if we continue to use V1, for how long?

I'm assuming the 'we' refers to your usage of LAVA as B@D doesn't use V1 tests.
I'd recommend moving to V2!

Robert

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 3:29 PM, Robert Marshall
<robert.marshall@...> wrote:

Zoran


"zoran.stojsavljevic.de" <zoran.stojsavljevic.de@...> writes:

Hello Robert,

As I am continuing to investigate this issue with the testing
framework, apparently Linaro does NOT support anymore Lava V1
(decisively), they already switched to Lava V2 (please, see forwarded
email from Neil Williams).

As my understanding is, they introduced Lava V2 in 2017.11 version. So
far, they've deleted all the databases with the Lava V1 test results
(I guess, this applies for Linaro environment usage).

We've been using LAVA v 2 from the start (well at least from the 0.9
release and maybe earlier). We're still using LAVA 2017-7

https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage

gives the relevant versions.

I am forced to switch abruptly to Lava V2, and here is what I assume
after 2 day investigation (yesterday and ongoing today) on Lava:
[1] The Lava Version 1 (as well as CIP RT kernel) testing scripts did
not change at all;
[2] The Lava Version 2 setup did change, in the sense that there are
some new technologies used (jinja2 U-Boot parsers);
[3] The communication architecture between lava-server and lava-worker
did change (ZMQ and XML-RPC), but this is hidden beneath/under the
hood (does not affect anything on testing level, Linaro claims this
way of the communication between Master and Worker is faster)...

Seems an easy change to go, but knowing these humongous Python
frameworks (YOCTO Project as obvious example), nothing is easy these
days.

Does anybody work on Lava Version 2 these days? Would be interesting
to try the whole CIP testing framework I am trying to bring up with
Lava Version 2.

I'm not sure what you mean here as V2 is under active development?

Any opinions/provisos on this topic?

(please, do note that I have changed my email address on CIP mailing
list, introducing the third [more convenient] gmail email for others).

Thank you,
Zoran Stojsavljevic

---------- Forwarded message ----------
From: Zoran S <zoran.stojsavljevic.de@...>
Date: Fri, Feb 9, 2018 at 2:01 PM
Subject: Re: [Lava-users] [HW target questions] Pointers from Lava
test suite to the HW target
To: Neil Williams <neil.williams@...>
Cc: Lava Users Mailman list <lava-users@...>


Hello Neil,

Please, hold your horses. I am very new to all this, and I need some
time to get to the Lava architecture, meaning to get in proper ways.
In the sense, I'll try to rephrase the questions, and the working
context, since your answers make me more confused than bring the
viable solutions... :-(

After reading your email, there are the major addendums to this
context, so let me rephrase/rework my initial email.
_______

My aim is to use Lava V2 (since Lava V1 is not supported anymore). Let it be.

As I mentioned, I would like to use Beagle Bone Black (BBB) to Lava
worker, and from Lava apache to set the proper context for testing BBB
HW.

But also, for the starters (seems the step in between) I can do QEMU
(the problem is I have no idea how to do this outside of YOCTO
Project).

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

I am running Lava v2017/7. Which supports ONLY V1. On Virtual Machine
Debian Stretch (using VBox as VMM).

root@stretch:/home/vagrant# uname -a
Linux stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
root@stretch:/home/vagrant# dpkg-query -W -f '${version}\n' 'lava-server'
2017.07

My problem here is that I can build the newest version of the
Hashicorp debian/stretch64 using vagrant:
https://app.vagrantup.com/debian/boxes/stretch64

But I am NOT able to include the newest Lava into this setup, since
apt-get install Lava (and components) is bringing me Lava V1 (even
very old version 2016.12-2)???

Q1: how I can bring here the newest Lava 2018.01 (only Version 2
compliant)? What the apt-get install Lava-2018.01 or similar command
(I am Fedora monkey, as considering my host setup. Lava I am
bringing/installing into the VM over VBox VMM)?

In other words, what is the specific command I need to use in scripts
to bring proper Lava 2018.01??? Or any another command?
Here is what is now used: sudo DEBIAN_FRONTEND=noninteractive apt-get
-y install lava -t stretch-backports

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

I already use the newest 2017.11 BBB U-Boot, so anyway I need to tap
(and change some strings) into the following files (as of my best
understanding):
root@stretch:/# find . -name base-uboot.jinja2
./etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
root@stretch:/# find . -name beaglebone-black.jinja2
./etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
root@stretch:/# find . -name qemu.jinja2
./etc/lava-server/dispatcher-config/device-types/qemu.jinja2
root@stretch:/#

Q2: I need here some examples, if they exist. How I can build these
scripts, or should I use existing? Or to do something more to hook
Lava to ser2net?

I already know: interrupt_prompt: {{ interrupt_prompt|default('Hit any
key to stop autoboot') }} <<===== String MUST be changed for U-Boot
2017.11!

Q3: I see that base-uboot.jinja2 is a base file. Should I include it
it other .jinja2 files using:
{% extends 'base-uboot.jinja2' %}

That looks like you have to manage the power control using
a graphical interface and that's not going to work...

Let us skip for now this question (I would like to simplify). PDU is
for now not of importance. Focusing to make minimalistic approach to
work.

That will show up in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

The whole ttyUSB0 using ser2net TCP is done already, works like a
charm. In VM, as pass-through device.

Q4: do I need to use something special here to hook ser2net terminal to Lava?

root@stretch:/# cd /dev/serial
root@stretch:/dev/serial# ls -al
total 0
drwxr-xr-x 4 root root 80 Feb 9 11:29 .
drwxr-xr-x 19 root root 3140 Feb 9 11:32 ..
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-id
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-path
root@stretch:/dev/serial#

That is all managed by LAVA in the test job submission. TFTP is already configured.

in.tftp works like a charm (tftp-ing from VM to U-Boot BBB), as well
as dhcpd (dnsmasq, also from VM). So, I have to trust you if you say
that I do not need to do anything on that.

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

In fact, this was not my question (I have latest 2017.11 U-Boot there
on mmcblk1 which is /boot partition, works perfectly).

Q5: I wanted to know do I need to set up U-Boot scripts in some ways
(as /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
suggests, as example)??? In other words, make U-Boot environment more
as .jinja2 suggests?

Start with QEMU, make sure that's working and get an understanding
of how that works with the device dictionary, test job submission,
test shell definitions and general LAVA UI usage.

Q6: So, what I need to do here? I use YOCTO project to build all BBB
embedded Linux ingredients, uImage, .dtb and root tree, how I can use
QEMU from YOCTO as independent .exe in Lava context??? Or, maybe,
after all, I can try real image?!

I apologize for the long email. Some features are already solved
(tftp, edhcp, ser2net), so we do not need to include them further (as
I now understand).

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 10:23 AM, Neil Williams <neil.williams@...> wrote:

On 9 February 2018 at 09:00, Zoran S <zoran.stojsavljevic.de@...>
wrote:

Hello to the Lava users,

I am the new Lava user. My aim is to use Lava (for now V1)

Welcome. Please take care with terminology. V1 is already dead, please don't
start there. We will be unable to help you with your V1 setup. Your later
comments refer to elements from V2, so please take care with which bits of
documentation you are following.

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

setup for my testing, from the beginning just to hook-up my Beagle Bone
Black (BBB) to Lava worker, and from Lava apache to set the proper context
for testing BBB HW.

As I am reading Lava framework, I got the following impression about the
test suite:
[1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup;

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

[2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and
POFF HW platform);

That looks like you have to manage the power control using a graphical
interface and that's not going to work. You'll need to investigate how to
control that unit using the command line only. Does it have a telnet API or
other serial API? That will all be down to you to configure. You might want
to look at using an APC PDU instead as those already have support in lavapdu
(or can use SNMP if you configure the worker appropriately).

[3] I need to hook-up ser2net interface (which I already have working over
TCP) to the Lava. so Lava can control it;

That goes into the device dictionary, as per the docs. Do you have the FTDI
cable to attach to the BBB to get the serial connection? That will show up
in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

[4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which
will be FTPed and set in memory for board setup and testing).

TFTP, not FTP.

That is all managed by LAVA in the test job submission. TFTP is already
configured.

Question 1: Does manual have some Beagle Bone Black U-Boot default
scripts, which should be provisioned to the BBB U-Boot for the correct Lava
U-Boot behavior?

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some
explanation as working example how to do these points?

Those are mostly specific to your local setup.

Question 3: Anything else I missed for the proper Lava test setting?

Start with QEMU, make sure that's working and get an understanding of how
that works with the device dictionary, test job submission, test shell
definitions and general LAVA UI usage.

Thank you in advance,
Zoran

_____________________________________________

Lava-users mailing list
Lava-users@...
https://lists.linaro.org/mailman/listinfo/lava-users

Neil Williams
=============
neil.williams@...
http://www.linux.codehelp.co.uk/

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

Hello Robert,

You are correct. I am (as I email to the list about V2) finding more
info about the Lava framework.

The fact is that, since Lava 2017.2 Version 2 is first usable version
along with Version 1. Both versions coexist from Lava 2017.2 till Lava
2017.9. Lava 2017.9 was the last one to have both versions (and
Version 1 latest and greatest release). From Lava 2017.11 there is
ONLY one version in it: Version 2. Now, every months Linaro releases
new Lava version, and currently they are at 2018.2.

So, Lava 2017.7 (used for by CIP testing now) is both V1 and V2 compliant.

There is a significant difference between Version 1 and Version 2,
considering test scripts: V1 uses JSON test job submissions, V2 uses
YAML test job submissions.

So, here I made a mistake. I was under impression that the test script
format did not change, transiting from V1 to V2. Eeeeeeeek. Wrong!

The call here is: to use Version 1 or Version 2 from now on, that is
the question? And if we continue to use V1, for how long?

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 3:29 PM, Robert Marshall
<robert.marshall@...> wrote:

Zoran


"zoran.stojsavljevic.de" <zoran.stojsavljevic.de@...> writes:

Hello Robert,

As I am continuing to investigate this issue with the testing
framework, apparently Linaro does NOT support anymore Lava V1
(decisively), they already switched to Lava V2 (please, see forwarded
email from Neil Williams).

As my understanding is, they introduced Lava V2 in 2017.11 version. So
far, they've deleted all the databases with the Lava V1 test results
(I guess, this applies for Linaro environment usage).

We've been using LAVA v 2 from the start (well at least from the 0.9
release and maybe earlier). We're still using LAVA 2017-7

https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage

gives the relevant versions.

I am forced to switch abruptly to Lava V2, and here is what I assume
after 2 day investigation (yesterday and ongoing today) on Lava:
[1] The Lava Version 1 (as well as CIP RT kernel) testing scripts did
not change at all;
[2] The Lava Version 2 setup did change, in the sense that there are
some new technologies used (jinja2 U-Boot parsers);
[3] The communication architecture between lava-server and lava-worker
did change (ZMQ and XML-RPC), but this is hidden beneath/under the
hood (does not affect anything on testing level, Linaro claims this
way of the communication between Master and Worker is faster)...

Seems an easy change to go, but knowing these humongous Python
frameworks (YOCTO Project as obvious example), nothing is easy these
days.

Does anybody work on Lava Version 2 these days? Would be interesting
to try the whole CIP testing framework I am trying to bring up with
Lava Version 2.

I'm not sure what you mean here as V2 is under active development?

Any opinions/provisos on this topic?

(please, do note that I have changed my email address on CIP mailing
list, introducing the third [more convenient] gmail email for others).

Thank you,
Zoran Stojsavljevic

---------- Forwarded message ----------
From: Zoran S <zoran.stojsavljevic.de@...>
Date: Fri, Feb 9, 2018 at 2:01 PM
Subject: Re: [Lava-users] [HW target questions] Pointers from Lava
test suite to the HW target
To: Neil Williams <neil.williams@...>
Cc: Lava Users Mailman list <lava-users@...>


Hello Neil,

Please, hold your horses. I am very new to all this, and I need some
time to get to the Lava architecture, meaning to get in proper ways.
In the sense, I'll try to rephrase the questions, and the working
context, since your answers make me more confused than bring the
viable solutions... :-(

After reading your email, there are the major addendums to this
context, so let me rephrase/rework my initial email.
_______

My aim is to use Lava V2 (since Lava V1 is not supported anymore). Let it be.

As I mentioned, I would like to use Beagle Bone Black (BBB) to Lava
worker, and from Lava apache to set the proper context for testing BBB
HW.

But also, for the starters (seems the step in between) I can do QEMU
(the problem is I have no idea how to do this outside of YOCTO
Project).

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

I am running Lava v2017/7. Which supports ONLY V1. On Virtual Machine
Debian Stretch (using VBox as VMM).

root@stretch:/home/vagrant# uname -a
Linux stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
root@stretch:/home/vagrant# dpkg-query -W -f '${version}\n' 'lava-server'
2017.07

My problem here is that I can build the newest version of the
Hashicorp debian/stretch64 using vagrant:
https://app.vagrantup.com/debian/boxes/stretch64

But I am NOT able to include the newest Lava into this setup, since
apt-get install Lava (and components) is bringing me Lava V1 (even
very old version 2016.12-2)???

Q1: how I can bring here the newest Lava 2018.01 (only Version 2
compliant)? What the apt-get install Lava-2018.01 or similar command
(I am Fedora monkey, as considering my host setup. Lava I am
bringing/installing into the VM over VBox VMM)?

In other words, what is the specific command I need to use in scripts
to bring proper Lava 2018.01??? Or any another command?
Here is what is now used: sudo DEBIAN_FRONTEND=noninteractive apt-get
-y install lava -t stretch-backports

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

I already use the newest 2017.11 BBB U-Boot, so anyway I need to tap
(and change some strings) into the following files (as of my best
understanding):
root@stretch:/# find . -name base-uboot.jinja2
./etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
root@stretch:/# find . -name beaglebone-black.jinja2
./etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
root@stretch:/# find . -name qemu.jinja2
./etc/lava-server/dispatcher-config/device-types/qemu.jinja2
root@stretch:/#

Q2: I need here some examples, if they exist. How I can build these
scripts, or should I use existing? Or to do something more to hook
Lava to ser2net?

I already know: interrupt_prompt: {{ interrupt_prompt|default('Hit any
key to stop autoboot') }} <<===== String MUST be changed for U-Boot
2017.11!

Q3: I see that base-uboot.jinja2 is a base file. Should I include it
it other .jinja2 files using:
{% extends 'base-uboot.jinja2' %}

That looks like you have to manage the power control using
a graphical interface and that's not going to work...

Let us skip for now this question (I would like to simplify). PDU is
for now not of importance. Focusing to make minimalistic approach to
work.

That will show up in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

The whole ttyUSB0 using ser2net TCP is done already, works like a
charm. In VM, as pass-through device.

Q4: do I need to use something special here to hook ser2net terminal to Lava?

root@stretch:/# cd /dev/serial
root@stretch:/dev/serial# ls -al
total 0
drwxr-xr-x 4 root root 80 Feb 9 11:29 .
drwxr-xr-x 19 root root 3140 Feb 9 11:32 ..
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-id
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-path
root@stretch:/dev/serial#

That is all managed by LAVA in the test job submission. TFTP is already configured.

in.tftp works like a charm (tftp-ing from VM to U-Boot BBB), as well
as dhcpd (dnsmasq, also from VM). So, I have to trust you if you say
that I do not need to do anything on that.

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

In fact, this was not my question (I have latest 2017.11 U-Boot there
on mmcblk1 which is /boot partition, works perfectly).

Q5: I wanted to know do I need to set up U-Boot scripts in some ways
(as /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
suggests, as example)??? In other words, make U-Boot environment more
as .jinja2 suggests?

Start with QEMU, make sure that's working and get an understanding
of how that works with the device dictionary, test job submission,
test shell definitions and general LAVA UI usage.

Q6: So, what I need to do here? I use YOCTO project to build all BBB
embedded Linux ingredients, uImage, .dtb and root tree, how I can use
QEMU from YOCTO as independent .exe in Lava context??? Or, maybe,
after all, I can try real image?!

I apologize for the long email. Some features are already solved
(tftp, edhcp, ser2net), so we do not need to include them further (as
I now understand).

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 10:23 AM, Neil Williams <neil.williams@...> wrote:

On 9 February 2018 at 09:00, Zoran S <zoran.stojsavljevic.de@...>
wrote:

Hello to the Lava users,

I am the new Lava user. My aim is to use Lava (for now V1)

Welcome. Please take care with terminology. V1 is already dead, please don't
start there. We will be unable to help you with your V1 setup. Your later
comments refer to elements from V2, so please take care with which bits of
documentation you are following.

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

setup for my testing, from the beginning just to hook-up my Beagle Bone
Black (BBB) to Lava worker, and from Lava apache to set the proper context
for testing BBB HW.

As I am reading Lava framework, I got the following impression about the
test suite:
[1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup;

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

[2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and
POFF HW platform);

That looks like you have to manage the power control using a graphical
interface and that's not going to work. You'll need to investigate how to
control that unit using the command line only. Does it have a telnet API or
other serial API? That will all be down to you to configure. You might want
to look at using an APC PDU instead as those already have support in lavapdu
(or can use SNMP if you configure the worker appropriately).

[3] I need to hook-up ser2net interface (which I already have working over
TCP) to the Lava. so Lava can control it;

That goes into the device dictionary, as per the docs. Do you have the FTDI
cable to attach to the BBB to get the serial connection? That will show up
in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

[4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which
will be FTPed and set in memory for board setup and testing).

TFTP, not FTP.

That is all managed by LAVA in the test job submission. TFTP is already
configured.

Question 1: Does manual have some Beagle Bone Black U-Boot default
scripts, which should be provisioned to the BBB U-Boot for the correct Lava
U-Boot behavior?

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some
explanation as working example how to do these points?

Those are mostly specific to your local setup.

Question 3: Anything else I missed for the proper Lava test setting?

Start with QEMU, make sure that's working and get an understanding of how
that works with the device dictionary, test job submission, test shell
definitions and general LAVA UI usage.

Thank you in advance,
Zoran

_____________________________________________

Lava-users mailing list
Lava-users@...
https://lists.linaro.org/mailman/listinfo/lava-users

Neil Williams
=============
neil.williams@...
http://www.linux.codehelp.co.uk/

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

Hello CIP members,

As I look at the git repository, there are multiple PREEMPT_RT branches:

* linux-4.4.y-cip-rt-rebase
* linux-4.4.y-cip-rt
* linux-4.4.y-cip-rt-patches

I'm trying to understand if I want to develop a product using RT, what branch should I be tracking and pulling into my local git repo?


I would think that locally, I would have some git repository that I will pull from CIP and merge into my own tree. I would also be pushing that to some local server to share with the other team members in my group.

Therefore, the 'rebase' thing doesn't make sense to me because if you are pushing a rebased tree, that means you are changing the existing parent history and doing a simple 'git pull' doesn't work so well (like what you have with the linux-next tree).


Do I just fetch and merge from 'linux-4.4.y-cip-rt' periodically as I develop my product, and that will play nicely with the local commits that I am also making and pushing locally to my repository?

Thank you,
Chris

Zoran


"zoran.stojsavljevic.de" <zoran.stojsavljevic.de@...> writes:

Hello Robert,

As I am continuing to investigate this issue with the testing
framework, apparently Linaro does NOT support anymore Lava V1
(decisively), they already switched to Lava V2 (please, see forwarded
email from Neil Williams).

As my understanding is, they introduced Lava V2 in 2017.11 version. So
far, they've deleted all the databases with the Lava V1 test results
(I guess, this applies for Linaro environment usage).

We've been using LAVA v 2 from the start (well at least from the 0.9
release and maybe earlier). We're still using LAVA 2017-7

https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage

gives the relevant versions.

I am forced to switch abruptly to Lava V2, and here is what I assume
after 2 day investigation (yesterday and ongoing today) on Lava:
[1] The Lava Version 1 (as well as CIP RT kernel) testing scripts did
not change at all;
[2] The Lava Version 2 setup did change, in the sense that there are
some new technologies used (jinja2 U-Boot parsers);
[3] The communication architecture between lava-server and lava-worker
did change (ZMQ and XML-RPC), but this is hidden beneath/under the
hood (does not affect anything on testing level, Linaro claims this
way of the communication between Master and Worker is faster)...

Seems an easy change to go, but knowing these humongous Python
frameworks (YOCTO Project as obvious example), nothing is easy these
days.

Does anybody work on Lava Version 2 these days? Would be interesting
to try the whole CIP testing framework I am trying to bring up with
Lava Version 2.

I'm not sure what you mean here as V2 is under active development?

Any opinions/provisos on this topic?

(please, do note that I have changed my email address on CIP mailing
list, introducing the third [more convenient] gmail email for others).

Thank you,
Zoran Stojsavljevic

---------- Forwarded message ----------
From: Zoran S <zoran.stojsavljevic.de@...>
Date: Fri, Feb 9, 2018 at 2:01 PM
Subject: Re: [Lava-users] [HW target questions] Pointers from Lava
test suite to the HW target
To: Neil Williams <neil.williams@...>
Cc: Lava Users Mailman list <lava-users@...>


Hello Neil,

Please, hold your horses. I am very new to all this, and I need some
time to get to the Lava architecture, meaning to get in proper ways.
In the sense, I'll try to rephrase the questions, and the working
context, since your answers make me more confused than bring the
viable solutions... :-(

After reading your email, there are the major addendums to this
context, so let me rephrase/rework my initial email.
_______

My aim is to use Lava V2 (since Lava V1 is not supported anymore). Let it be.

As I mentioned, I would like to use Beagle Bone Black (BBB) to Lava
worker, and from Lava apache to set the proper context for testing BBB
HW.

But also, for the starters (seems the step in between) I can do QEMU
(the problem is I have no idea how to do this outside of YOCTO
Project).

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

I am running Lava v2017/7. Which supports ONLY V1. On Virtual Machine
Debian Stretch (using VBox as VMM).

root@stretch:/home/vagrant# uname -a
Linux stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
root@stretch:/home/vagrant# dpkg-query -W -f '${version}\n' 'lava-server'
2017.07

My problem here is that I can build the newest version of the
Hashicorp debian/stretch64 using vagrant:
https://app.vagrantup.com/debian/boxes/stretch64

But I am NOT able to include the newest Lava into this setup, since
apt-get install Lava (and components) is bringing me Lava V1 (even
very old version 2016.12-2)???

Q1: how I can bring here the newest Lava 2018.01 (only Version 2
compliant)? What the apt-get install Lava-2018.01 or similar command
(I am Fedora monkey, as considering my host setup. Lava I am
bringing/installing into the VM over VBox VMM)?

In other words, what is the specific command I need to use in scripts
to bring proper Lava 2018.01??? Or any another command?
Here is what is now used: sudo DEBIAN_FRONTEND=noninteractive apt-get
-y install lava -t stretch-backports

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

I already use the newest 2017.11 BBB U-Boot, so anyway I need to tap
(and change some strings) into the following files (as of my best
understanding):
root@stretch:/# find . -name base-uboot.jinja2
./etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
root@stretch:/# find . -name beaglebone-black.jinja2
./etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
root@stretch:/# find . -name qemu.jinja2
./etc/lava-server/dispatcher-config/device-types/qemu.jinja2
root@stretch:/#

Q2: I need here some examples, if they exist. How I can build these
scripts, or should I use existing? Or to do something more to hook
Lava to ser2net?

I already know: interrupt_prompt: {{ interrupt_prompt|default('Hit any
key to stop autoboot') }} <<===== String MUST be changed for U-Boot
2017.11!

Q3: I see that base-uboot.jinja2 is a base file. Should I include it
it other .jinja2 files using:
{% extends 'base-uboot.jinja2' %}

That looks like you have to manage the power control using
a graphical interface and that's not going to work...

Let us skip for now this question (I would like to simplify). PDU is
for now not of importance. Focusing to make minimalistic approach to
work.

That will show up in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

The whole ttyUSB0 using ser2net TCP is done already, works like a
charm. In VM, as pass-through device.

Q4: do I need to use something special here to hook ser2net terminal to Lava?

root@stretch:/# cd /dev/serial
root@stretch:/dev/serial# ls -al
total 0
drwxr-xr-x 4 root root 80 Feb 9 11:29 .
drwxr-xr-x 19 root root 3140 Feb 9 11:32 ..
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-id
drwxr-xr-x 2 root root 60 Feb 9 11:29 by-path
root@stretch:/dev/serial#

That is all managed by LAVA in the test job submission. TFTP is already configured.

in.tftp works like a charm (tftp-ing from VM to U-Boot BBB), as well
as dhcpd (dnsmasq, also from VM). So, I have to trust you if you say
that I do not need to do anything on that.

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

In fact, this was not my question (I have latest 2017.11 U-Boot there
on mmcblk1 which is /boot partition, works perfectly).

Q5: I wanted to know do I need to set up U-Boot scripts in some ways
(as /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2
suggests, as example)??? In other words, make U-Boot environment more
as .jinja2 suggests?

Start with QEMU, make sure that's working and get an understanding
of how that works with the device dictionary, test job submission,
test shell definitions and general LAVA UI usage.

Q6: So, what I need to do here? I use YOCTO project to build all BBB
embedded Linux ingredients, uImage, .dtb and root tree, how I can use
QEMU from YOCTO as independent .exe in Lava context??? Or, maybe,
after all, I can try real image?!

I apologize for the long email. Some features are already solved
(tftp, edhcp, ser2net), so we do not need to include them further (as
I now understand).

Thank you,
Zoran
_______

On Fri, Feb 9, 2018 at 10:23 AM, Neil Williams <neil.williams@...> wrote:

On 9 February 2018 at 09:00, Zoran S <zoran.stojsavljevic.de@...>
wrote:

Hello to the Lava users,

I am the new Lava user. My aim is to use Lava (for now V1)

Welcome. Please take care with terminology. V1 is already dead, please don't
start there. We will be unable to help you with your V1 setup. Your later
comments refer to elements from V2, so please take care with which bits of
documentation you are following.

What version of LAVA are you running? On Debian Jessie or Debian Stretch?

setup for my testing, from the beginning just to hook-up my Beagle Bone
Black (BBB) to Lava worker, and from Lava apache to set the proper context
for testing BBB HW.

As I am reading Lava framework, I got the following impression about the
test suite:
[1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup;

Jinja is V2 - so things are already getting confused. You can use the U-Boot
that comes with the BBB but you will need to account for any changes in
prompts etc. in the device configuration.

[2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and
POFF HW platform);

That looks like you have to manage the power control using a graphical
interface and that's not going to work. You'll need to investigate how to
control that unit using the command line only. Does it have a telnet API or
other serial API? That will all be down to you to configure. You might want
to look at using an APC PDU instead as those already have support in lavapdu
(or can use SNMP if you configure the worker appropriately).

[3] I need to hook-up ser2net interface (which I already have working over
TCP) to the Lava. so Lava can control it;

That goes into the device dictionary, as per the docs. Do you have the FTDI
cable to attach to the BBB to get the serial connection? That will show up
in /dev/serial/by-id/ and that becomes part of the ser2net configuration.

[4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which
will be FTPed and set in memory for board setup and testing).

TFTP, not FTP.

That is all managed by LAVA in the test job submission. TFTP is already
configured.

Question 1: Does manual have some Beagle Bone Black U-Boot default
scripts, which should be provisioned to the BBB U-Boot for the correct Lava
U-Boot behavior?

Typically, for the BBB, we use the mainline U-Boot that comes from Debian.
https://packages.debian.org/stretch/u-boot-omap

Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some
explanation as working example how to do these points?

Those are mostly specific to your local setup.

Question 3: Anything else I missed for the proper Lava test setting?

Start with QEMU, make sure that's working and get an understanding of how
that works with the device dictionary, test job submission, test shell
definitions and general LAVA UI usage.

Thank you in advance,
Zoran

_____________________________________________

Lava-users mailing list
Lava-users@...
https://lists.linaro.org/mailman/listinfo/lava-users

Neil Williams
=============
neil.williams@...
http://www.linux.codehelp.co.uk/