Linux Foundation Wiki

project collaboration site

User Tools

Site Tools


civilinfrastructureplatform:ciptestingreferencetestcases

B@D Reference Test Cases (5/5)

These instructions provide some Example Tests and Test Cases you can use to validate your CIP Board-at-Desk Single-Developer (B@D) v1.0 Virtual Machine (VM) or from which, you can learn how all of the tooling works together.

This set of instructions assumes you have already connected the Beaglebone Black board to the machine where you have installed B@D. If that is not the case please go back to the Beaglebone Black Setup & Configuration wiki page, which is step 3.

It is also assumed you have already created an initramfs with BusyBox for the Beaglebone Black, that is step 4. If that is not the case, please go back to the wiki page where the creation is explained.

If you have a kernel that you have built on another machine that you wish to test with B@D please refer to Test 6.

Test #1: Running the Health Check for the QEMU Device

Prerequisites:

  • A working CIP Board-at-Desk Single-Developer (B@D) v1.0 Virtual Machine

Procedure:

1. On your host machine, open a web browser and enter the following in the address box:

http://localhost:8080

2. The LAVA Home Page is displayed in your web browser. Log in to the web server as the superuser:

  • Click the login link in the upper right-hand corner of the Lava Server website
  • Enter the username: lavauser
  • Enter the password: mylava1234

3. Click on Scheduler and then select All Devices.

4. Click on the qemu01 Hostname

5. Click the Force Health Check button.

6. The results are displayed in the web page as the test runs. When the test is done, the status of the Job will show as Complete at the top of the page.

This is what the start of the Health Check looks like:

 Root tmp directory created at /var/lib/lava/dispatcher/tmp/20
 start: 0 validate
 Validating that https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz exists
 no device environment specified
 validate duration: 0.70
 start: 1 deployimages (max 720s)
 start: 1.1 download_retry (max 720s)
 start: 1.1.1 http_download (max 720s)
 Using gz decompression
 downloading https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz as /var/lib/lava/dispatcher/tmp/20/deployimages-GRCaQT/stretch-2.img 
 <snip>

This is what the end of a successful test looks like:

 </snip>
 case: finalize
 definition: lava
 result: pass
 level: 4
 extra: ...
 Cleanup: removing /var/lib/lava/dispatcher/tmp/20 

7. You can see an example of a successful test log file here: the QEMU Test results


Test #2: Building the CIP Kernel with Kernel CI

See the build howto for the method.


Test #3: Running the Health Check for the Beaglebone Black Device

Prerequisites:

  • A working CIP Board-at-Desk Single-Developer (B@D) v1.0 Virtual Machine
  • A Beaglebone Black that is powered up, connected to the LAN with an ethernet cable and connected to the host machine with an FTDI cable.
  • A locally built CIP kernel

Procedure:

1. Check the status of the (4) blue user LED's on the Beaglebone Black. If they are all off, manually reboot the board by pressing the reset button (S1) or disconnect and reconnect the power cable to the board.

2. On your host machine, open a web browser and enter the following in the address box:

http://localhost:8080

3. The LAVA Home Page is displayed in your web browser. Log in to the web server as the superuser:

  • Click the login link in the upper right-hand corner of the Lava Server website
  • Enter the username: lavauser
  • Enter the password: mylava1234

4. In a Vagrant ssh session change to the ~/git-repos/linux-cip directory.

vagrant@guest:~$ cd ~/git-repos/linux-cip

5. Set the TREE_NAME environment variable.

vagrant@guest:~/git-repos/linux-cip$ export TREE_NAME=cip-example

Note: This should be the same name you used when you built the kernel.

6. Create a test - from within the linux-cip git repository.

vagrant@guest:~/git-repos/linux-cip$ /vagrant/scripts/create_test.sh /vagrant/tests/bbb_debian_local.yaml ~/mytest-bbb.yaml

Note: create_test.sh must be run in the linux-cip directory so that the script can retrieve the git settings.

Note: mytest-bbb.yaml is an example filename. Substitute your own test file name in its place.

7. Replace the current health check (see Health Check configuration for the location of the health check) with the contents of the yaml file you generated in the previous step.

8. Click on Scheduler and then select All Devices.

8. Click on the bbb01 Hostname

9. Click the Force Health Check button.

10. The results are displayed in the web page as the test runs. When the test is done, the status of the Job will show as Complete at the top of the page.

This is what the start of the Health Check looks like:

 Root tmp directory created at /var/lib/lava/dispatcher/tmp/22
 start: 0 validate
 Validating that http://localhost:8010/initramfs/initramfs.cpio.gz exists
 Validating that http://localhost:8010/cip-test/cip_v4.4.83/v4.4.75-cip8/arm/omap2plus_defconfig/zImage exists
 Validating that http://localhost:8010/cip-test/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/dtbs/am335x-boneblack.dtb exists
 Validating that http://localhost:8010/cip-test/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/modules.tar.xz exists
 no device environment specified
 booti, bootm and bootz are being deprecated soon, please use 'image','uimage' or 'zimage'
 device may need manual intervention to reboot
 validate duration: 0.02
 start: 1 tftp-deploy (max 240s)
 start: 1.1 download_retry (max 240s)
 start: 1.1.1 http_download (max 240s)
 Not decompressing ramdisk as can be used compressed.
 No compression specified.
 downloading http://localhost:8010/initramfs/initramfs.cpio.gz as  /var/lib/lava/dispatcher/tmp/22/tftp-deploy-wJ5b76/initramfs.cpio.gz
 <snip>

This is what the end of a successful test looks like:

 </snip>
 case: finalize
 definition: lava
 result: pass
 level: 4
 extra: ...
 Cleanup: removing /var/lib/lava/dispatcher/tmp/22

Note: After running the health check, if the (4) user LED's are all off, manually reboot the board by pressing the reset button (S1) or disconnect and reconnect the power cable to the board before re-running the health check.

8. You can see an example of a successful test log file the Beaglebone Black Test results .


Test #4: Testing the CIP Kernel on the Beaglebone Black

Prerequisites:

  • A working CIP Board-at-Desk Single-Developer (B@D) v1.0 Virtual Machine
  • A Beaglebone Black that is powered up, connected to the LAN with an ethernet cable and connected to the host machine with an FTDI cable.

Procedure:

1. Check the status of the (4) blue user LED's on the Beaglebone Black. If they are all off, manually reboot the board by pressing the reset button (S1) or disconnect and reconnect the power cable to the board.

2. On your host machine, open a web browser and enter the following in the address box:

http://localhost:8080

3. The LAVA Home Page is displayed in your web browser. Log in to the web server as the superuser:

  • Click the login link in the upper right-hand corner of the Lava Server website
  • Enter the username: lavauser
  • Enter the password: mylava1234

4. From the LAVA homepage, click on Scheduler and Submit Job

5. Copy the contents of the /vagrant/tests/bbb_debian_ramdisk_test.yaml and paste them into the job definition box on the Submit Job page.

6. Modify the job's “Action Block” to include the paths to the files generated by Kernel CI.

  • Modify the kernel url to point to the zImage file link
    • The link will look like: http://localhost:8010/cip-example/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/zImage
  • Modify the modules url to point to the modules.tar.xz file link and change the compression type to “xz”.
    • The link will look like: http://localhost:8010/cip-example/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/modules.tar.xz
  • Modify the dtb url to point to the Beaglebone Black's dtb file link
  • The link will look like: http://localhost:8010/cip-example/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/dtbs/am335x-boneblack.dtb

7. Click on the Validate button under the job definition box to make sure the syntax of the job is correct.

8. Click the Submit button. You will see the following message:

 Job submission successful!
 Job with ID <number> has been created.
 To view the full job list click here.

9. Click on the Job ID Number to view the log as the job runs.

10. The results are displayed in the web page as the test runs. When the test is done, the status of the Job will show as Complete at the top of the page.

This is what the start of the Health Check looks like:

 Root tmp directory created at /var/lib/lava/dispatcher/tmp/11
 start: 0 validate
 Validating that http://localhost:8010/initramfs/initramfs.cpio.gz exists
 Validating that http://localhost:8010/cip-releaseTest/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/zImage exists
 Validating that http://localhost:8010/cip-releaseTest/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/dtbs/am335x-boneblack.dtb exists
 Validating that http://localhost:8010/cip-releaseTest/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/modules.tar.xz exists
 no device environment specified
 booti, bootm and bootz are being deprecated soon, please use 'image','uimage' or 'zimage'
 device may need manual intervention to reboot
 validate duration: 3.01
 start: 1 tftp-deploy (max 240s)
 start: 1.1 download_retry (max 240s)
 start: 1.1.1 http_download (max 240s)
 Not decompressing ramdisk as can be used compressed.
 No compression specified.
 downloading http://localhost:8010/initramfs/initramfs.cpio.gz as /var/lib/lava/dispatcher/tmp/11/tftp-deploy-Blt0p9/initramfs.cpio.gz 
 <snip>

This is what the end of a successful test looks like:

 </snip>
 case: finalize
 definition: lava
 result: pass
 level: 4
 duration: 0.105773925781
 extra: ...
 Cleanup: removing /var/lib/lava/dispatcher/tmp/11

Test #5: Use lava-tool utility

Prerequisites:

  • A working CIP Board-at-Desk Single-Developer (B@D) v1.0 Virtual Machine
  • A Beaglebone Black that is powered up, connected to the LAN with an ethernet cable and connected to the host machine with an FTDI cable.
  • A built kernel for the Beaglebone Black (see Test #3)
  • The Beaglebone Black has a current successful health check (it is marked as online in LAVA)

Procedure:

1. Change to the ~/git-repos/linux-cip directory.

vagrant@guest:~$ cd ~/git-repos/linux-cip

2. If you have not already done so, you will need to create an authentication token

  In the LAVA web interface, click on API->Authentication Tokens and then on the 'new' button, 
  give it a description and then click the 'View Token Hash' button and copy the displayed hash value.
  Then ''lava-tool auth-add http://lavauser@localhost:8080/RPC2
  Paste token for http://lavauser@localhost:8080/RPC2/: **paste token - which will not be echoed**

3. Set the TREE_NAME environment variable.

vagrant@guest:~/git-repos/linux-cip$ export TREE_NAME=cip-example

Note: This should be the same name you used when you built the kernel.

4. Create a test for use with the lava-tool utility from within the linux-cip git repository.

vagrant@guest:~/git-repos/linux-cip$ /vagrant/scripts/create_test.sh /vagrant/tests/bbb_debian_local.yaml ~/mytest-bbb.yaml

Note: create_test.sh must be run in the linux-cip directory so that the script can retrieve the git settings.

Note: mytest-bbb.yaml is an example filename. Substitute your own test file name in its place.

5. Run the lava-tool command to submit the job to LAVA.

vagrant@guest:~/git-repos/linux-cip$ lava-tool submit-job http://lavauser@localhost:8080/RPC2 ~/mytest-bbb.yaml

  submitted as job: http://localhost:8080/scheduler/job/12

Note: Please see the LAVA documentation for help writing tests in LAVA,

6. On your host machine, open a web browser and navigate to the LAVA Website:

http://localhost:8080

7. Click on the Scheduler menu and select the All Jobs option.

8. Click on the View Job Results icon for the top job to watch the build.

9. The results are displayed in the web page as the test runs. When the test is done, the status of the Job will show as Complete at the top of the page.

This is what the start of the test looks like:

 Root tmp directory created at /var/lib/lava/dispatcher/tmp/12
 start: 0 validate
 Validating that http://localhost:8010/initramfs/initramfs.cpio.gz exists
 Validating that http://localhost:8010/cip-example/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/zImage exists
 Validating that http://localhost:8010/cip-example/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/dtbs/am335x-boneblack.dtb exists
 Validating that http://localhost:8010/cip-example/cip_v4.4.83/v4.4.83-cip8/arm/omap2plus_defconfig/modules.tar.xz exists
 no device environment specified
 booti, bootm and bootz are being deprecated soon, please use 'image','uimage' or 'zimage'
 device may need manual intervention to reboot
 validate duration: 1.07
 start: 1 tftp-deploy (max 240s)
 start: 1.1 download_retry (max 240s)
 start: 1.1.1 http_download (max 240s)
 Not decompressing ramdisk as can be used compressed.
 No compression specified.
 downloading http://localhost:8010/initramfs/initramfs.cpio.gz as /var/lib/lava/dispatcher/tmp/11/tftp-deploy-iZGX26/initramfs.cpio.gz
 <snip>

This is what the end of a successful test looks like:

 </snip>
 finalize duration: 0.10
 case: finalize
 definition: lava
 result: pass
 level: 4
 duration: 0.10351395607
 extra: ...
 Cleanup: removing /var/lib/lava/dispatcher/tmp/12

Note: After running the test, if the (4) user LED's are all off, manually reboot the board by pressing the reset button (S1) or disconnect and reconnect the power cable to the board before re-running the test.

9. You can see an example of a successful test log file the Beaglebone Black Test results .

Test #6: Testing Externally Built Kernels

Prerequisites:

  • A working CIP Board-at-Desk Single-Developer (B@D) v1.0 Virtual Machine
  • A board on which to test that kernel.
  • A defined device and device dictionary for the new device. Copy the dictionary entry into /etc/lava-server/dispatcher-config/devices (see /vagrant/integration-scripts/configure_lava.sh for examples).

Procedure:

  • Copy the kernel associated files and ramdisk onto the Virtual Machine. This can be done either by putting the files in a subdirectory of board-at-desk-single-dev in which case they will end up as a subdirectory of /vagrant. Or use
         vagrant scp $PATH_TO/kernelFiles.tgz :kernelFiles.tgz  
  • Move the files into a single directory within /var/www/images/kernel-ci. So, for example, if testing the Renesas iwg20m, create /var/www/images/kernel-ci/renesas/iwg20m.
  • Then in your health check reference the files as http://localhost/renesas/iwg20m/uImage etc..

Return to the B@D feature page

civilinfrastructureplatform/ciptestingreferencetestcases.txt · Last modified: 2017/11/02 15:00 by rajmarshall