Project

General

Profile

Feature #3155

execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW setup

Added by laforge 13 days ago. Updated 5 days ago.

Status:
In Progress
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
04/10/2018
Due date:
% Done:

20%

Spec Reference:

Description

We want to execute the BTS_Tests.ttcn against all real hardware BTS models of our LTHW setup.

Hardware Setup

On the hardware side, his means, we need to
  • add a C123 with RF cabling to the "modem ports" of the setup
  • be able to power cycle this C123 from software
  • attach the C123 UART via CP2103 USB-UART to the main unit

Software Setup

We will need to be able to execute the BTS_Tests.ttcn on the gsm tester main unit. This could be done either natively or via the existing docker containers. In any case, we don't want to build the ttcn source on the low-power APU, but we want that the compiled test suite is copied/transferred to the APU and then executed there.

We also want to make sure that we have proper locking/exclusivity with the osmo-gsm-tester stack, so that we either run osmo-gsm-tester or BTS_Tests.ttcn.

Finally, this should all be started from jenkins.osmocom.org.

It probably makes sense (as usual) to start with the R&D setup and then replicate the setup in production.

History

#2 Updated by laforge 13 days ago

https://wiki.cuvoodoo.info/doku.php?id=osmotoserial is the project I was originally referring-to.

We still want to build it into an enclosure, though.

#3 Updated by laforge 11 days ago

  • Priority changed from Normal to High

#4 Updated by mschramm 10 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

We got three osmotoserial PCBA by tsaitgaist. I got them working in a C123 and in C118 (only a C155 did not come up as expected).

No additional power switch is needed, as the PCBA controls the phone power itself by listening to the state of DTR signal on the USB serial (CP2104).

#5 Updated by mschramm 10 days ago

Only on the C123 the MS-147 plug connects reasonably, but must be fixed somehow too. On at least one C118 used here, it simply falls off. Maybe we strip the phones' enclosures to achieve better contact.

#6 Updated by pespin 6 days ago

List of what's needed after first evaluation:
  • HW:
    • A main unit (re-use osmo-gsm-tester main unit)
    • A motorola Cyxz phone plugged with a serial interface plugged in and a software based way to power ir on/off from the main unit.
    • a sysmobts (re-use the osmo-gsm-tester one).
    • RF network setup between motorola phone and sysmobts.
  • SW:
    • tools needed to flash and control the motorola Cxyz. Provide either debian packages or a docker image with them. Stuff needed: osmocon, firmware blob, flashing tool?
    • trial borrowed from osmo-gsm-tester build jobs: osmo-bts-sysmo, those will be copied to sysmobts
    • trial borrowed from osmo-gsm-tester build jobs: osmo-bsc. It will configure the sysmobts through OML and tell it to connect via RSL to TTTCN3 test.
    • docker image containing a built and running BTS_Tests.ttcn

Flashing the phone doesn't seem to be required, it can be controlled directly by osmocon through serial at boot time(https://osmocom.org/projects/baseband/wiki/Osmocon)

Then, we need a jenkins job which does the following:
  1. Get artifacts from following jobs: osmo-gsm-tester_build-osmo-bts-sysmo osmo-gsm-tester_build-osmo-msc
  2. Fetch latest already built docker images
  3. run a shell/python script to do all the job.
  4. Use the produced junit file.
The script should do the following:
  1. Prepare a osmo-bts-sysmo.cfg, osmo-bsc.cfg according to specific setup (ip address, etc., have a look at the one used in BTS_Tests.ttcn)
  2. Start osmo-bsc using the prepared osmo-bsc.
  3. scp the osmo-bts-trial trial to the sysmobts and start the osmo-bts-sysmo process.
  4. Build/download the osmocom firmware.
  5. Start osmocon binary, be it in a docker image or via trial.
  6. Start latest Bts_Tests ttcn3 docker image, which should start the tests automatically.
  7. Wait until Bts_Tests image is done
  8. Tear down everything: osmocon, sysmobts processes, osmo-bsc, docker images
  9. Store results in artficats and provide a junit file.

Locking mechanism between osmo-gsm-tester and this new run job is not required because it's already integrated in jenkins (the main unit node only executes 1 job in parallel so far).

The job should actually be a matrix job, as we actually want to run the tests for:
- sysmobts
- octphy (requires osmo-bts trial for osmo-bts-octphy)
- sysmocell500 (requires osmo-bts trial for osmo-bts-trx)
- nanobts

Remark:
It may actually make sense to reuse osmo-gsm-tester to start and manage all those processes (BTS+BSC), and provide a specific test which waits for a specific event in the system to finish (for instance a unix socket receiving some stuff).
For instance the shell script starting osmo-gsm-tester with that mentioned test, then starting osmocon, then starting the docker image with the ttcn3 tests.

#7 Updated by laforge 6 days ago

On Tue, Apr 17, 2018 at 05:20:41PM +0000, pespin [REDMINE] wrote:

List of what's needed after first evaluation:
  • HW:
    • A main unit (re-use osmo-gsm-tester main unit)
    • A motorola Cyxz phone plugged with a serial interface plugged in and a software based way to power ir on/off from the main unit.

let's focus on C123 or C118, and make sure it's the same model everywhere. I can bring
more phones from home, as needed.

  • SW:
    • tools needed to flash and control the motorola Cxyz. Provide either debian packages or a docker image with them. Stuff needed: osmocon, firmware blob, flashing tool?
there is no "flashing" involved, it's all just loaded into ram. You need the following bits
and pieces from osmocom-bb.git:
  • osmocon
  • layer1 firmware image (cross-compiled with ancient toolchain)
    • make sure to enable transmit in the firmware Makefile!
  • docker image containing a built and running BTS_Tests.ttcn

It still remains to be seen if the docker image can be executed on the APU (resource wise)

We clearly don't have to build the docker image on the APU itself, but we have to run it there.

Flashing the phone doesn't seem to be required, it can be controlled directly by osmocon through serial at boot time(https://osmocom.org/projects/baseband/wiki/Osmocon)

ACK.

  1. Fetch latest already built docker images

we can push those from the build hosts to our own registry (We do have a container running on
admin2.sysmocom.de, but it's not used/tested yet)

  1. Build/download the osmocom firmware.

I think it's fine to build it on jenkins build slaves (I think we even have an osmocom-bb build verification job already,
it's just not storing the resulting builds and probably builds without TX enabled)

  1. Start latest Bts_Tests ttcn3 docker image, which should start the tests automatically.

correct, if the phone, BTS, BSC(!) and 'osmocon' are all running, executing the tests works exactly
like in the virtualized environment with trxcon+fake_trx.

#8 Updated by mschramm 5 days ago

  • % Done changed from 10 to 20

A phone is now installed with an osmotoserial PCBA in the R&D test rig. However, it switches on immediately, though no terminal process is working for this serial (right now it is /dev/ttyUSB14) which is different to the behaviour seen on my local machine. I'll leave this to pespin; because of OsmoDevCon I don't think that progress on this will be made before upcoming week.

Also available in: Atom PDF