Date   

[test issue #99] Issues with installing when running behind a web proxy

Zoran
 

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


Re: [EOL for Lava Version 1] Lava Version 2 replacing Lava Version 1

Robert Marshall <robert.marshall@...>
 

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


Re: [EOL for Lava Version 1] Lava Version 2 replacing Lava Version 1

Zoran
 

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


Re: [EOL for Lava Version 1] Lava Version 2 replacing Lava Version 1

Robert Marshall <robert.marshall@...>
 

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


Re: [EOL for Lava Version 1] Lava Version 2 replacing Lava Version 1

Zoran
 

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


How to develop on the RT version

Chris Brandt <Chris.Brandt@...>
 

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


Re: [EOL for Lava Version 1] Lava Version 2 replacing Lava Version 1

Robert Marshall <robert.marshall@...>
 

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/


[EOL for Lava Version 1] Lava Version 2 replacing Lava Version 1

Zoran
 

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).

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.

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/


Re: [PATCH 0/7] Add i2c/iic support for r8a7743

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2018-02-01 at 13:46 +0000, Biju Das wrote:
This patch series aims to add i2c/iic support for r8a7743 SoC.

Backported dt-bindings patch
Backported per-Generation fallbacks

It is tested against linux-v4.4.112-cip18

This patch depends on the below patch series
https://lists.cip-project.org/pipermail/cip-dev/2018-January/000820.html
All looks good to me.  I've applied and pushed these changes.

Ben.

Biju Das (4):
  dt-bindings: i2c: Document r8a7743/5 support
  ARM: dts: r8a7743: Add I2C DT support
  dt-bindings: i2c: sh_mobile: Document r8a7743/5 support
  ARM: dts: r8a7743: Add IIC cores to dtsi

Geert Uytterhoeven (1):
  dt-bindings: i2c: Spelling s/propoerty/property/

Simon Horman (2):
  i2c: rcar: Add per-Generation fallback bindings
  i2c: sh_mobile: Add per-Generation fallback bindings

 Documentation/devicetree/bindings/i2c/i2c-imx.txt  |   2 +-
 Documentation/devicetree/bindings/i2c/i2c-rcar.txt |  35 ++++--
 .../devicetree/bindings/i2c/i2c-sh_mobile.txt      |  20 ++-
 Documentation/devicetree/bindings/i2c/i2c-sirf.txt |   2 +-
 arch/arm/boot/dts/r8a7743.dtsi                     | 137 +++++++++++++++++++++
 drivers/i2c/busses/i2c-rcar.c                      |   5 +-
 drivers/i2c/busses/i2c-sh_mobile.c                 |   4 +-
 7 files changed, 186 insertions(+), 19 deletions(-)
--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 00/10] Add SMP support for r8a7743

Ben Hutchings <ben.hutchings@...>
 

On Wed, 2018-01-31 at 11:15 +0000, Biju Das wrote:
This patch series aims to add SMP support for r8a7743 SoC.

It is tested against linux-v4.4.112-cip18
All looks good to me. I've applied and pushed these changes.

Ben.

Biju Das (4):
  ARM: shmobile: Add pm support for r8a7743
  dt-bindings: apmu: Document r8a7743 support
  ARM: dts: r8a7743: Add APMU node and second CPU core
  ARM: dts: r8a7743: Add OPP table for frequency scaling

Geert Uytterhoeven (4):
  ARM: shmobile: apmu: Move #ifdef CONFIG_SMP to cover more functions
  ARM: shmobile: apmu: Add debug resource reset for secondary CPU boot
  ARM: shmobile: apmu: Allow booting secondary CPU cores in debug mode
  ARM: dts: r8a7743: Add missing clock for secondary CA15 CPU core

Magnus Damm (2):
  ARM: shmobile: apmu: Add APMU DT support via Enable method
  devicetree: bindings: Renesas APMU and SMP Enable method

 Documentation/devicetree/bindings/arm/cpus.txt     |  1 +
 .../devicetree/bindings/power/renesas,apmu.txt     | 29 +++++++
 arch/arm/boot/dts/r8a7743.dtsi                     | 25 ++++++
 arch/arm/mach-shmobile/platsmp-apmu.c              | 94 +++++++++++++++++++++-
 arch/arm/mach-shmobile/pm-rcar-gen2.c              |  3 +
 5 files changed, 150 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/renesas,apmu.txt
--
Ben Hutchings
Software Developer, Codethink Ltd.


Increase of visibility of the work done in Gitlab: proposal

Agustín Benito Bethencourt <agustin.benito@...>
 

Hi,

 

in order to increase the visibility of the work done in Gitlab I suggest one of these two actions:

* Create a mailing list for development notifications where we can send the notifications of the commits made in gitlab, including the diffs.

* Send the notifications to this mailing list and let users filter them.

 

I do not expect heavy traffic as long as we do not include Ben's repo.

 

In the same line, I suggest to do the same with IRC, expecting limited traffic.

 

Best Regards

 

--

Agustín Benito Bethencourt

Principal Consultant

Codethink Ltd


Re: [ANNOUNCE] 4.4.112-cip18-rt11

Daniel Wagner <daniel.wagner@...>
 

Hi Daniel,

Thanks for letting me know. The correct URL is

https://www.kernel.org/pub/linux/kernel/people/wagi/cip-rt/4.4/
Sorry, but there is no " patch-4.4.112-cip18.xz" on that URL either.
Argh :) This should read patch-4.4.112-cip18-rt11.patch.xz

Also shouldn't we have 3 patches? lts + cip + rt
I just create the patches on top of the CIP version.
Oh, I see. the vanilla linux url (linux-4.4.tar.xz) confused me.
Then, what we should use is this, right?:
https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git/snapshot/linux-cip-4.4.112-cip18.tar.gz
https://www.kernel.org/pub/linux/kernel/people/wagi/cip-rt/4.4/patch-4.4.112-cip18-rt11.patch.xz
Yes. these are the right URLs.

The scripts for
this are the ones we use for the stable-rt trees. I don't know the
patches are useful or not. I don't mind dropping the patch services if
no one needs it. Neither Greg nor Ben are creating patch releases so
doing the cip-rt patches seems like a waste of time.
Personally, I don't mind if you stop releasing the patches. I have tested
the cip-rt kernel from your git tree and so far I didn't have problems
with long real-time latencies. I also confirmed that meltdown is fixed.
Right, I'll stop doing the patches.

Good to hear that the cip-rt works for you!

Thanks,
Daniel


Re: [ANNOUNCE] 4.4.112-cip18-rt11

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: Daniel Wagner [mailto:daniel.wagner@...]
Sent: Tuesday, February 06, 2018 7:28 PM
To: Daniel Sangorrin; cip-dev@...
Subject: Re: [cip-dev] [ANNOUNCE] 4.4.112-cip18-rt11

Hi Daniel,

On 02/06/2018 02:32 AM, Daniel Sangorrin wrote:
-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Daniel Wagner
...
Or to build 4.4.112-cip18-rt11 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.112-cip18.xz
This URL doesn't work.
Thanks for letting me know. The correct URL is

https://www.kernel.org/pub/linux/kernel/people/wagi/cip-rt/4.4/
Sorry, but there is no " patch-4.4.112-cip18.xz" on that URL either.

Also shouldn't we have 3 patches? lts + cip + rt
I just create the patches on top of the CIP version.
Oh, I see. the vanilla linux url (linux-4.4.tar.xz) confused me.
Then, what we should use is this, right?:
https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git/snapshot/linux-cip-4.4.112-cip18.tar.gz
https://www.kernel.org/pub/linux/kernel/people/wagi/cip-rt/4.4/patch-4.4.112-cip18-rt11.patch.xz

The scripts for
this are the ones we use for the stable-rt trees. I don't know the
patches are useful or not. I don't mind dropping the patch services if
no one needs it. Neither Greg nor Ben are creating patch releases so
doing the cip-rt patches seems like a waste of time.
Personally, I don't mind if you stop releasing the patches. I have tested
the cip-rt kernel from your git tree and so far I didn't have problems
with long real-time latencies. I also confirmed that meltdown is fixed.

Thanks,
Daniel


Re: [ANNOUNCE] 4.4.112-cip18-rt11

Daniel Wagner <daniel.wagner@...>
 

Hi Daniel,

On 02/06/2018 02:32 AM, Daniel Sangorrin wrote:
-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Daniel Wagner
...
Or to build 4.4.112-cip18-rt11 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.112-cip18.xz
This URL doesn't work.
Thanks for letting me know. The correct URL is

https://www.kernel.org/pub/linux/kernel/people/wagi/cip-rt/4.4/

Also shouldn't we have 3 patches? lts + cip + rt
I just create the patches on top of the CIP version. The scripts for
this are the ones we use for the stable-rt trees. I don't know the
patches are useful or not. I don't mind dropping the patch services if
no one needs it. Neither Greg nor Ben are creating patch releases so
doing the cip-rt patches seems like a waste of time.

Thanks,
Daniel


Re: [ANNOUNCE] 4.4.112-cip18-rt11

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Daniel Wagner
Sent: Monday, January 29, 2018 3:03 AM
To: Daniel Wagner
Cc: cip-dev@...
Subject: Re: [cip-dev] [ANNOUNCE] 4.4.112-cip18-rt11

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
My scripts still need some love. The tree is here

git://git.kernel.org/pub/scm/linux/kernel/git/wagi/linux-cip-rt.git

branch: v4.4-rt
Head SHA1: 92b397fd34fac354e00f1ffdd51e2121e01a5ee5
Not only the repository, but the branch is also mistaken. It should be linux-4.4.y-cip-rt.

Thanks,
Daniel Sangorrin


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


Re: [ANNOUNCE] 4.4.112-cip18-rt11

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Daniel Wagner
...
Or to build 4.4.112-cip18-rt11 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.112-cip18.xz
This URL doesn't work.
Also shouldn't we have 3 patches? lts + cip + rt

Thanks,
Daniel Sangorrin

http://www.kernel.org/pub/linux/kernel/people/wagi/cip-rt/4.4/patch-4.4.112-cip18-rt11.patch.xz
Enjoy!
Daniel
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Unable to attend Feb. 5 TSC

Jeff ErnstFriedman <jernstfriedman@...>
 

Dear members of the CIP TSC,

My name is Jeff ErnstFriedman and I will be stepping in with program management for CIP. I am pleased to meet everyone and would like to make myself available for any questions/comments.

Unfortunately for this upcoming TSC meeting on Feb 5. I will not be able to attend as I have a prescheduled appt. to get some tests done, it is an overnight on Sunday and I will not be cleared to leave until after the meeting concludes. Unfortunately these things are difficult to reschedule.

If you record the meeting in Zoom, I will followup with minutes and action items.

Please accept my apologies and I look forward to working with this project going forward.

Jeff ErnstFriedman
2201 Broadway #604, Oakland, CA 94612
mobile: 510.593.1367
skype: jeffrey.ernstfriedman
twitter: @namdeirf


CIP: Will miss meeting on Monday

Annie Fisher <afisher@...>
 

Greetings all,

Unfortunately, I have a conflict for the TSC and Marketing Meetings on Monday, so will not be able to attend.

Cheers,
Annie

Annie Fisher, MPA CSM
Program Manager, The Linux Foundation
Location & Time-zone: San Francisco, CA, PT
email: afisher@...


Sent with Mixmax


[PATCH 7/7] ARM: dts: r8a7743: Add IIC cores to dtsi

Biju Das <biju.das@...>
 

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 f523405f2a22cc0c30701ea0cb3671dc0abbcda1)
(Modified clocks,power domain property and removed resets property)
Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
---
arch/arm/boot/dts/r8a7743.dtsi | 52 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index b7be573..9255582 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -25,6 +25,9 @@
i2c3 = &i2c3;
i2c4 = &i2c4;
i2c5 = &i2c5;
+ i2c6 = &iic0;
+ i2c7 = &iic1;
+ i2c8 = &iic3;
};

cpus {
@@ -382,6 +385,55 @@
status = "disabled";
};

+ iic0: i2c@e6500000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,iic-r8a7743",
+ "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
+ reg = <0 0xe6500000 0 0x425>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp3_clks R8A7743_CLK_IIC0>;
+ dmas = <&dmac0 0x61>, <&dmac0 0x62>,
+ <&dmac1 0x61>, <&dmac1 0x62>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
+ iic1: i2c@e6510000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,iic-r8a7743",
+ "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
+ reg = <0 0xe6510000 0 0x425>;
+ interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp3_clks R8A7743_CLK_IIC1>;
+ dmas = <&dmac0 0x65>, <&dmac0 0x66>,
+ <&dmac1 0x65>, <&dmac1 0x66>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
+ iic3: i2c@e60b0000 {
+ /* doesn't need pinmux */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,iic-r8a7743",
+ "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
+ reg = <0 0xe60b0000 0 0x425>;
+ interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7743_CLK_IICDVFS>;
+ dmas = <&dmac0 0x77>, <&dmac0 0x78>,
+ <&dmac1 0x77>, <&dmac1 0x78>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
scifa0: serial@e6c40000 {
compatible = "renesas,scifa-r8a7743", "renesas,scifa";
reg = <0 0xe6c40000 0 0x40>;
--
2.7.4


[PATCH 6/7] dt-bindings: i2c: sh_mobile: Document r8a7743/5 support

Biju Das <biju.das@...>
 

Document i2c Device Tree support for RZ/G1[ME]
(also known as r8a774[35]) SoCs. They are compatible with
R-Car Gen2 SoC family. No driver change is required as the
initialisation sequence is currently the same as for the
R-Car Gen2 fallback binding.

Signed-off-by: Biju Das <biju.das@...>
Acked-by: Simon Horman <horms+renesas@...>
Signed-off-by: Wolfram Sang <wsa@...>
(cherry picked from commit 6c448f04c83713c49be7baf341ed6a04d7493a15)
Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Chris Paterson <chris.paterson2@...>
---
Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
index 7716acc..4bfb89e 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -4,6 +4,8 @@ Required properties:
- compatible :
- "renesas,iic-r8a73a4" (R-Mobile APE6)
- "renesas,iic-r8a7740" (R-Mobile A1)
+ - "renesas,iic-r8a7743" (RZ/G1M)
+ - "renesas,iic-r8a7745" (RZ/G1E)
- "renesas,iic-r8a7790" (R-Car H2)
- "renesas,iic-r8a7791" (R-Car M2-W)
- "renesas,iic-r8a7792" (R-Car V2H)
@@ -11,7 +13,8 @@ Required properties:
- "renesas,iic-r8a7794" (R-Car E2)
- "renesas,iic-r8a7795" (R-Car H3)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
- - "renesas,rcar-gen2-iic" (generic R-Car Gen2 compatible device)
+ - "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1
+ compatible device)
- "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device)
- "renesas,rmobile-iic" (generic device)

--
2.7.4

8781 - 8800 of 9641