Date   

[Git][cip-project/cip-testing/testing][master] 2 commits: remove 0001.patch

Agustin Benito Bethencourt
 

Agustin Benito Bethencourt pushed to branch master at cip-project / cip-testing / testing

Commits:

  • ddbe6ede
    by Don Brown at 2017-01-20T12:34:08-05:00
    remove 0001.patch
    
  • 40d4405b
    by Don Brown at 2017-02-22T18:43:47+00:00
    Update README.md

2 changed files:

Changes:

  • 0001.patch deleted
    1
    - integration-scripts/install_backend.sh      |  8 +++++++-
    
    2
    - integration-scripts/install_build_script.sh |  9 ++++++++-
    
    3
    - integration-scripts/install_frontend.sh     |  8 +++++++-
    
    4
    - scripts/setup-dev-env.sh                    | 11 +++++++++++
    
    5
    - 4 files changed, 33 insertions(+), 3 deletions(-)
    
    6
    - create mode 100644 scripts/setup-dev-env.sh
    
    7
    -
    
    8
    -diff --git a/integration-scripts/install_backend.sh b/integration-scripts/install_backend.sh
    
    9
    -index 72a974033a3c..157e7184e349 100755
    
    10
    ---- a/integration-scripts/install_backend.sh
    
    11
    -+++ b/integration-scripts/install_backend.sh
    
    12
    -@@ -4,7 +4,13 @@
    
    13
    - # Install kernelci backend
    
    14
    -
    
    15
    - cd $HOME && mkdir git-repos && cd git-repos
    
    16
    --git clone https://github.com/kernelci/kernelci-backend-config.git kernelci-backend
    
    17
    -+
    
    18
    -+GIT_SRC="https://github.com/kernelci/kernelci-backend-config.git"
    
    19
    -+if [ -d /vagrant/kernelci-backend-config ]; then
    
    20
    -+    GIT_SRC=/vagrant/kernelci-backend-config
    
    21
    -+fi
    
    22
    -+git clone $GIT_SRC kernelci-backend
    
    23
    -+
    
    24
    - cp /vagrant/config/secrets-backend.yml kernelci-backend/secrets.yml
    
    25
    -
    
    26
    - # Fixme: Don't let ansible try to create the file in the first place.
    
    27
    -diff --git a/integration-scripts/install_build_script.sh b/integration-scripts/install_build_script.sh
    
    28
    -index 322619317af6..879aaed01792 100755
    
    29
    ---- a/integration-scripts/install_build_script.sh
    
    30
    -+++ b/integration-scripts/install_build_script.sh
    
    31
    -@@ -3,7 +3,14 @@
    
    32
    - # Copyright (C) 2016, Siemens AG, Wolfgang Mauerer <wolfgang.mauerer@...>
    
    33
    - # SPDX-License-Identifier:     Apache-2.0
    
    34
    -
    
    35
    --cd $HOME && git clone https://github.com/kernelci/kernelci-build.git
    
    36
    -+cd $HOME
    
    37
    -+
    
    38
    -+GIT_SRC="https://github.com/kernelci/kernelci-build.git"
    
    39
    -+if [ -d /vagrant/kernelci-build ]; then
    
    40
    -+    GIT_SRC=/vagrant/kernelci-build
    
    41
    -+fi
    
    42
    -+git clone $GIT_SRC
    
    43
    -+
    
    44
    - cd kernelci-build
    
    45
    -
    
    46
    - MASTER_KEY=`cat $HOME/backend-admin-token.txt`
    
    47
    -diff --git a/integration-scripts/install_frontend.sh b/integration-scripts/install_frontend.sh
    
    48
    -index 48ab91ab83ce..251ef89d28f3 100755
    
    49
    ---- a/integration-scripts/install_frontend.sh
    
    50
    -+++ b/integration-scripts/install_frontend.sh
    
    51
    -@@ -4,7 +4,13 @@
    
    52
    - # Install kernelci frontend
    
    53
    -
    
    54
    - cd $HOME/git-repos
    
    55
    --git clone https://github.com/kernelci/kernelci-frontend-config.git kernelci-frontend
    
    56
    -+
    
    57
    -+GIT_SRC="https://github.com/kernelci/kernelci-frontend-config.git"
    
    58
    -+if [ -d /vagrant/kernelci-frontend-config ]; then
    
    59
    -+    GIT_SRC=/vagrant/kernelci-frontend-config
    
    60
    -+fi
    
    61
    -+git clone $GIT_SRC kernelci-frontend
    
    62
    -+
    
    63
    - sed -i kernelci-frontend/roles/install-app/tasks/main.yml \
    
    64
    -     -e 's/kernelci\/kernelci-frontend.git/siemens\/kernelci-frontend.git/'
    
    65
    -
    
    66
    -diff --git a/scripts/setup-dev-env.sh b/scripts/setup-dev-env.sh
    
    67
    -new file mode 100644
    
    68
    -index 000000000000..59c13b233065
    
    69
    ---- /dev/null
    
    70
    -+++ b/scripts/setup-dev-env.sh
    
    71
    -@@ -0,0 +1,11 @@
    
    72
    -+#!/bin/sh
    
    73
    -+
    
    74
    -+if [ ! -f "Vagrantfile" ]; then
    
    75
    -+    echo "script is supposed to be run from the top folder where"
    
    76
    -+    echo "the Vagrantfile is."
    
    77
    -+    exit 1
    
    78
    -+fi
    
    79
    -+
    
    80
    -+git clone https://github.com/kernelci/kernelci-backend-config.git
    
    81
    -+git clone https://github.com/kernelci/kernelci-build.git
    
    82
    -+git clone https://github.com/kernelci/kernelci-frontend-config.git
    
    83
    -

  • README.md
    1
    -# Kernel CI for the Civil Infrastructure Platform #
    
    1
    +# Board at desk - single dev description  #
    
    2 2
     
    
    3
    -This repository provides vagrant infrastructure that allows users/labs
    
    4
    -to easily set up a kernel CI front- end backend tailored to the needs
    
    5
    -of the civil infrastructure platform (http://www.cip-platform.org).
    
    3
    +Board at desk - single dev is an effort to ease the deployment of KernelCI and LAVAv2 allowing
    
    4
    +a developer with a board connected to its machine test kernels. 
    
    5
    +In order to do so, a VM has been created with all the tools and configurations required. 
    
    6
    +The current technology used to create that VM is Vagrant. 
    
    6 7
     
    
    7
    -KernelCI Virtual Machine Setup & Configuration
    
    8
    +# Interesting links #
    
    8 9
     
    
    9
    -The current setup requires (2) Virtual Machines; one for KernelCI and the other for LAVA v2
    
    10
    +* Board at desk - single dev [feature page](https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage)
    
    11
    +* [Download](https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload) Board at desk - single dev.
    
    12
    +* Instructions to [download and set up Board at desk - single dev](https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevsetup).
    
    13
    +* [Connect and configure Beaglebone Black](https://wiki.linuxfoundation.org/civilinfrastructureplatform/beagleboneblackboard) to test the kernel on the board.
    
    14
    +* [CIP testing project home page](https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting)
    
    10 15
     
    
    11
    -Edit
    
    12
    -Setting up KernelCI VM
    
    16
    +# Contribute to the CIP testing project: #
    
    17
    +* Please read the Testing at [CIP FAQ](https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingfaq) to learn more about this action.
    
    18
    +* Join the technical mailing list ( [cip-dev](https://lists.cip-project.org/mailman/listinfo/cip-dev) ) to follow this effort.
    
    19
    +* Report a [bug](https://gitlab.com/cip-project/testing/boards). 
    
    13 20
     
    14
    -1. Install Vagrant
    
    15
    -
    
    16
    -[user@host ~] $ sudo apt-get install vagrant
    
    17
    -
    
    18
    -2. Install Oracle Virtualbox
    
    19
    -
    
    20
    -[user@host ~] $ sudo apt-get install virtualbox
    
    21
    -
    
    22
    -OR, if you downloaded Virtualbox from the Oracle website
    
    23
    -Note: This assumes you are running Ubuntu Xenial(16.04) 64-bit
    
    24
    -[user@host ~] $ cd Downloads
    
    25
    -[user@host Downloads] $ sudo dpkg -i virtualbox-5.1_5.1.8-111374-Ubuntu-xenial_amd64.deb
    
    26
    -
    
    27
    -3. Get the CIP KernelCI Project
    
    28
    -
    
    29
    -[user@host ~/git] $ git clone https://gitlab.com/cip-project/testing.git
    
    30
    -
    
    31
    -4. Change to the testing directory
    
    32
    -
    
    33
    -[user@host ~/git] $ cd testing
    
    34
    -
    
    35
    -5. Launch the KernelCI Virtual Machine
    
    36
    -
    
    37
    -[user@host ~/git/testing] $ vagrant up
    
    38
    -
    
    39
    -Note: Please ignore any warnings such as “GetPassWarning: Can not control echo on the terminal.” or “Warning: Password input may be echoed.” - These do not affect the operation of the KernelCI VM.
    
    40
    -
    
    41
    -6. Connect to the KernelCI VM through ssh using vagrant
    
    42
    -
    
    43
    -[user@host ~] $ vagrant ssh
    
    44
    -
    
    45
    -Edit
    
    46
    -Get CIP Kernel using git
    
    47
    -
    
    48
    -7. Change to the git-repos directory
    
    49
    -
    
    50
    -vagrant@guest:~$ cd git-repos
    
    51
    -
    
    52
    -8. Clone the Linux Kernel
    
    53
    -
    
    54
    -vagrant@guest:~/git-repos$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    
    55
    -
    
    56
    -9. Find the branch of the kernel version you want (i.e. 4.4.27)
    
    57
    -
    
    58
    -vagrant@guest:~/git-repos$ cd linux-stable
    
    59
    -
    
    60
    -vagrant@guest:~/git-repos/linux-stable$ git tag -l | grep 4.4.y
    
    61
    -
    
    62
    -10. Create a new branch using that tag.
    
    63
    -
    
    64
    -vagrant@guest:~/git-repos/linux-stable$ git checkout -b cip_v4.4.27 v4.4.27
    
    65
    -
    
    66
    -Edit
    
    67
    -Compile CIP Kernel
    
    68
    -
    
    69
    -11. Set the environment variables
    
    70
    -
    
    71
    -vagrant@guest:~/git-repos/linux-stable$ export TREE_NAME=cip-test
    
    72
    -
    
    73
    -vagrant@guest:~/git-repos/linux-stable$ export ARCH=arm
    
    74
    -
    
    75
    -vagrant@guest:~/git-repos/linux$ export CROSS_COMPILE=arm-linux-gnueabi-
    
    76
    -
    
    77
    -Note: Don't forget the dash (-) at the end of the CROSS_COMPILE line!
    
    78
    -
    
    79
    -12. Execute the build.py command
    
    80
    -
    
    81
    -vagrant@guest:~/git-repos/linux-stable$ ~/kernelci-build/build.py -c tinyconfig -p CIP-KernelCI
    
    82
    -
    
    83
    -13. The Web Server is already running in the background. when you navigate from page to page the logs are written to the screen. To get back to the command line, simply press Enter
    
    84
    -
    
    85
    -14. On your host machine, open a web browser and enter the following in the address box:
    
    86
    -
    
    87
    -http://localhost:5000
    
    88
    -
    
    89
    -15. You will see the KernelCI Website home page from which, you can navigate to the different builds and trees that you've created
    
    90
    - 


  • [Git][cip-project/cip-testing/board-at-desk-single-dev][master] 3 commits: Install python-selinux to fix kernelci-backend issue #168

    Agustin Benito Bethencourt
     

    Agustin Benito Bethencourt pushed to branch master at cip-project / cip-testing / board-at-desk-single-dev

    Commits:

    • 645520c6
      by Robert Marshall at 2017-11-06T15:19:06+00:00
      Install python-selinux to fix kernelci-backend issue #168
      
    • c3d64a3b
      by Robert Marshall at 2017-11-07T10:55:53+00:00
      Merge branch 'fix-selinux-error' into 'master'
      
      Install python-selinux to fix kernelci-backend issue #168
      
      See merge request cip-project/cip-testing/board-at-desk-single-dev!51
    • a2b0bba4
      by Robert Marshall at 2018-02-07T13:42:22+00:00
      Fix comment typo (port now 8080)
      

    2 changed files:

    Changes:

  • Vagrantfile
    ... ... @@ -41,7 +41,7 @@ Vagrant.configure(2) do |config|
    41 41
       config.vm.network :forwarded_port, guest: 8010, host: 8010
    
    42 42
       # Forward port 5000 for the KernelCI Frontend Web Server
    
    43 43
       config.vm.network :forwarded_port, guest: 5000, host: 5000
    
    44
    -  # Forward port 80 for the http Lava Frontend Web Server
    
    44
    +  # Forward port 8080 for the http Lava Frontend Web Server
    
    45 45
       config.vm.network :forwarded_port, guest: 8080, host: 8080
    
    46 46
       # Forward port 443 for the https Lava Frontend Web Server
    
    47 47
       config.vm.network :forwarded_port, guest: 443, host: 4443
    

  • integration-scripts/install_dependencies.sh
    ... ... @@ -32,7 +32,7 @@ sudo DEBIAN_FRONTEND=noninteractive apt-get -y update
    32 32
     sudo DEBIAN_FRONTEND=noninteractive apt-get -y upgrade
    
    33 33
     
    
    34 34
     # Install the dependencies
    
    35
    -sudo DEBIAN_FRONTEND=noninteractive apt-get -y install git python-pip python-dev python-concurrent.futures python-tornado libffi-dev libyaml-dev libssl-dev rng-tools python-requests ser2net telnet screen
    
    35
    +sudo DEBIAN_FRONTEND=noninteractive apt-get -y install git python-pip python-dev python-concurrent.futures python-tornado libffi-dev libyaml-dev libssl-dev rng-tools python-requests ser2net telnet screen python-selinux
    
    36 36
     
    
    37 37
     # Install the ARM, ARM-HF & ARM64 Toolchain
    
    38 38
     sudo DEBIAN_FRONTEND=noninteractive apt-get -y install gcc-arm-linux-gnueabi gcc-arm-linux-gnueabihf gcc-aarch64-linux-gnu
    


  • [Git][cip-project/cip-kernel-sec][master] 2 commits: Add fixed-by commit hash for CVE-2017-17857 in 4.14

    Agustin Benito Bethencourt
     


    [Git][cip-project/cip-testing/CIP-kernel-test-logs][master] 2 commits: add README

    Agustin Benito Bethencourt
     

    Agustin Benito Bethencourt pushed to branch master at cip-project / cip-testing / CIP-kernel-test-logs

    Commits:

    • 1681c453
      by Robert Marshall at 2017-07-07T14:56:31+01:00
      add README
      
    • 36cafa6d
      by Robert Marshall at 2017-10-16T11:48:15+01:00
      Update output for v1.0 #144
      

    2 changed files:

    Changes:

  • README.md

  • vagrant-up.output The diff for this file was not included because it is too large.

  • [Git][cip-project/cip-testing/imported-kernel-tests][master] 2 commits: Get install correct

    Agustin Benito Bethencourt
     

    Agustin Benito Bethencourt pushed to branch master at cip-project / cip-testing / imported-kernel-tests

    Commits:

    • bd25c959
      by Robert Marshall at 2017-07-25T14:02:02+01:00
      Get install correct
      
    • 95e5dd3d
      by Robert Marshall at 2017-07-25T14:38:13+01:00
      Initial commit
      

    2 changed files:

    Changes:

  • kselftest.yaml
    ... ... @@ -28,17 +28,17 @@ params:
    28 28
     
    
    29 29
     # Skip install deps and steps on minimal rootfs from LAVA test
    
    30 30
     # Example:
    
    31
    -# "skip_install": "all"
    
    32
    -install:
    
    33
    -    deps:
    
    34
    -        - libpopt-dev
    
    35
    -        - libcap-dev
    
    36
    -        - binutils-dev
    
    37
    -        - perl
    
    38
    -        - wget
    
    39
    -        - tar
    
    40
    -    steps:
    
    41
    -        - './'
    
    31
    +skip_install: all
    
    32
    +# install:
    
    33
    +#     deps:
    
    34
    +#         - libpopt-dev
    
    35
    +#         - libcap-dev
    
    36
    +#         - binutils-dev
    
    37
    +#         - perl
    
    38
    +#         - wget
    
    39
    +#         - tar
    
    40
    +#     steps:
    
    41
    +#         - './'
    
    42 42
     
    
    43 43
     run:
    
    44 44
         steps:
    

  • selftests/kselftest_install.sh
    1
    +#!/bin/bash
    
    2
    +#
    
    3
    +# Kselftest Install
    
    4
    +# Install kselftest tests
    
    5
    +# Author: Shuah Khan <shuahkh@...>
    
    6
    +# Copyright (C) 2015 Samsung Electronics Co., Ltd.
    
    7
    +
    
    8
    +# This software may be freely redistributed under the terms of the GNU
    
    9
    +# General Public License (GPLv2).
    
    10
    +
    
    11
    +install_loc=`pwd`
    
    12
    +
    
    13
    +main()
    
    14
    +{
    
    15
    +	if [ $(basename $install_loc) !=  "selftests" ]; then
    
    16
    +		echo "$0: Please run it in selftests directory ..."
    
    17
    +		exit 1;
    
    18
    +	fi
    
    19
    +	if [ "$#" -eq 0 ]; then
    
    20
    +		echo "$0: Installing in default location - $install_loc ..."
    
    21
    +	elif [ ! -d "$1" ]; then
    
    22
    +		echo "$0: $1 doesn't exist!!"
    
    23
    +		exit 1;
    
    24
    +	else
    
    25
    +		install_loc=$1
    
    26
    +		echo "$0: Installing in specified location - $install_loc ..."
    
    27
    +	fi
    
    28
    +
    
    29
    +	install_dir=$install_loc/kselftest
    
    30
    +
    
    31
    +# Create install directory
    
    32
    +	mkdir -p $install_dir
    
    33
    +# # Build tests
    
    34
    +# 	INSTALL_PATH=$install_dir make install
    
    35
    +}
    
    36
    +
    
    37
    +main "$@"


  • [Git][cip-project/cip-testing/board-at-desk-single-dev][master] 3 commits: Install python-selinux to fix kernelci-backend issue #168

    Agustin Benito Bethencourt
     

    Agustin Benito Bethencourt pushed to branch master at cip-project / cip-testing / board-at-desk-single-dev

    Commits:

    • 645520c6
      by Robert Marshall at 2017-11-06T15:19:06+00:00
      Install python-selinux to fix kernelci-backend issue #168
      
    • c3d64a3b
      by Robert Marshall at 2017-11-07T10:55:53+00:00
      Merge branch 'fix-selinux-error' into 'master'
      
      Install python-selinux to fix kernelci-backend issue #168
      
      See merge request cip-project/cip-testing/board-at-desk-single-dev!51
    • a2b0bba4
      by Robert Marshall at 2018-02-07T13:42:22+00:00
      Fix comment typo (port now 8080)
      

    2 changed files:

    Changes:

  • Vagrantfile
    ... ... @@ -41,7 +41,7 @@ Vagrant.configure(2) do |config|
    41 41
       config.vm.network :forwarded_port, guest: 8010, host: 8010
    
    42 42
       # Forward port 5000 for the KernelCI Frontend Web Server
    
    43 43
       config.vm.network :forwarded_port, guest: 5000, host: 5000
    
    44
    -  # Forward port 80 for the http Lava Frontend Web Server
    
    44
    +  # Forward port 8080 for the http Lava Frontend Web Server
    
    45 45
       config.vm.network :forwarded_port, guest: 8080, host: 8080
    
    46 46
       # Forward port 443 for the https Lava Frontend Web Server
    
    47 47
       config.vm.network :forwarded_port, guest: 443, host: 4443
    

  • integration-scripts/install_dependencies.sh
    ... ... @@ -32,7 +32,7 @@ sudo DEBIAN_FRONTEND=noninteractive apt-get -y update
    32 32
     sudo DEBIAN_FRONTEND=noninteractive apt-get -y upgrade
    
    33 33
     
    
    34 34
     # Install the dependencies
    
    35
    -sudo DEBIAN_FRONTEND=noninteractive apt-get -y install git python-pip python-dev python-concurrent.futures python-tornado libffi-dev libyaml-dev libssl-dev rng-tools python-requests ser2net telnet screen
    
    35
    +sudo DEBIAN_FRONTEND=noninteractive apt-get -y install git python-pip python-dev python-concurrent.futures python-tornado libffi-dev libyaml-dev libssl-dev rng-tools python-requests ser2net telnet screen python-selinux
    
    36 36
     
    
    37 37
     # Install the ARM, ARM-HF & ARM64 Toolchain
    
    38 38
     sudo DEBIAN_FRONTEND=noninteractive apt-get -y install gcc-arm-linux-gnueabi gcc-arm-linux-gnueabihf gcc-aarch64-linux-gnu
    


  • [PATCH 3/3] ARM: multi_v7_defconfig: Enable BQ32000 RTC driver

    Fabrizio Castro <fabrizio.castro@...>
     

    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


    [PATCH 2/3] ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig

    Fabrizio Castro <fabrizio.castro@...>
     

    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


    [PATCH 1/3] ARM: dts: iwg20d-q7: Add RTC support

    Fabrizio Castro <fabrizio.castro@...>
     

    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


    [PATCH 0/3] Add RTC support to iwg20d

    Fabrizio Castro <fabrizio.castro@...>
     

    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


    Codethink: report weeks 6 and 7

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

    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


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

    Zoran
     

    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


    Re: Meltdown and Spectre in CIP

    Ben Hutchings <ben.hutchings@...>
     

    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.


    [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/

    8341 - 8360 of 9214