Project

General

Profile

Bug #2721

OsmoTRX build verification job for arm

Added by laforge about 1 month ago. Updated 6 days ago.

Status:
Feedback
Priority:
High
Assignee:
Target version:
-
Start date:
12/07/2017
Due date:
% Done:

80%

Spec Reference:

Description

As OsmoTRX contains some neon optimizied ARM code, we should test whether this builds (and passes tests, if any?) on those platforms as part of our jenkins verification.


Related issues

Related to OsmoTRX - Bug #2720: arm build comple crash :arm/convert code Resolved 12/07/2017
Related to OsmoTRX - Bug #2826: osmo-trx: different output in convolve test between x86 vs neon vs neon-vfpv4 New 01/11/2018

History

#1 Updated by laforge about 1 month ago

  • Related to Bug #2720: arm build comple crash :arm/convert code added

#2 Updated by laforge 17 days ago

  • Assignee changed from sysmocom to pespin

#3 Updated by laforge 17 days ago

  • Priority changed from Normal to High

#4 Updated by pespin 11 days ago

  • Status changed from New to In Progress

So far I cleaned up some parts to remove libsqlite dependency in order to make it easier if we need to cross-compile for ARM with a toolchain.

I also did set up the autotest infra to have tests run during make check, and cleaned the existing test to run nicely with it. I also fixed a UDD socket bug that appeared while doing so.

Next steps:
- Add (if not exist yet) a test to check that the optimized instruction set parts work fine.
- Add script to build quemu machines for the different architectures with optimized instruction set.
- Run the tests in each different arch using make check.

#5 Updated by pespin 11 days ago

I pushed some patches which check convolute for x85 (SSSE3 + SSE4.1).

I am now working on ading support to test the NEON ones by using qemu. After some investgation and trials, I found there's 2 main ways of doing it:
- Building debian image with debootstrap into a directory and using chroot + qemu-arm-static to run anything in there (so no real VM running, but enough for our tests I think).
- Building debian image with debootstrap into a directory mounted from an .img file, then running a VM with qemu-arm, and modify the image to run some script we want.

So far, the easiest (and quickest runtime wise) is the first one. The main issue I'm facing right now is trying to remove any root access required to do the job, since it's going to run inside jenkins. debootstrap and chroot require root permissions. I tried using fakechroot+fakeroot as explained here [1], but it has the limitation that it only works if the arch (so loader) is the same both inside and outisde the chroot, which is not the case for us. We could make it to work by linking the /lib dir inside the chroot into the outside /etc/qemu-binfmt/arm/ in the jenkins slave, but that's really hacky and difficult to maintain.
I think I'll instead keep using usual chroot and run the script inside a user container using unshare.

Something like: unshare -U prepare_vm.sh

and prepare_vm.sh:

qemu-debootstrap --foreign --include="linux-image-armmp-lpae,libusb-dev,fakeroot" --arch=armhf stretch qemu-img/ http://ftp.de.debian.org/debian/ # requires sudo
test -f qemu-img/usr/bin/qemu-arm-static || cp "`which qemu-arm-static`" qemu-img/usr/bin/
chroot qemu-img "/debootstrap/debootstrap --second-stage" 
chroot qemu-img "apt-get update" 

[1] https://lists.debian.org/debian-embedded/2011/04/msg00001.html

#6 Updated by pespin 10 days ago

  • Related to Bug #2826: osmo-trx: different output in convolve test between x86 vs neon vs neon-vfpv4 added

#7 Updated by pespin 9 days ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 80

Provided jenkins.sh working locally in https://gerrit.osmocom.org/#/c/5763/
Once osmo-ci https://gerrit.osmocom.org/#/c/5763/ is merged, we can test it in jenkins and once it's working fine, merge it.

#8 Updated by pespin 6 days ago

I finally enabled some parts in jenkin.sh to download a prebuilt image from somewhere else instead of building it with debootstrap, but still using proot to be able to chroot and run everything in there as a non-root user. I was able to run the complete script (with debootstrap) in my local workstation, but not in debian9-lxc inside buildserver1. In there it fails while configuring systemd pkg which runs "adduser" which runs "chfn" which fails with "PAM: System Error". All I read so far points to a kernel change in 3.15 which changed how AUDIT works inside/outside containers, so it may work if running outside an lxc.

Also available in: Atom PDF