OsmocomBB compile testing / Re: libosmocore embedded build

[Craig Comstock]

I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose).

Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development.

-Craig


--------------------------------------------
On Thu, 5/18/17, Harald Welte <laforge at gnumonks.org> wrote:

 Subject: OsmocomBB compile testing / Re: libosmocore embedded build
 To: "André Boddenberg" <dr.blobb at gmail.com>
 Cc: baseband-devel at lists.osmocom.org, "OpenBSC" <openbsc at lists.osmocom.org>, "Vadim Yanitskiy" <axilirator at gmail.com>
 Date: Thursday, May 18, 2017, 1:24 PM
 
 Hi Andre and others.
 
 We currently have a series of patches from
 Vadim pending in gerrit for
 OsmocomBB. 
 They cannot move ahead, as we have no compile testing /
 jenkins job which would give this a +1.
 
 To resolve this, we should
 also start to have a jenkins compile testing
 job for OsmocomBB.  The "host" (PC)
 part of the code is built against
 regular
 libosmocore, just like e.g. openbsc or osmo-bts.  That
 should be
 possible even so far, and it might
 make sense to start with that.
 
 Basically you need to:
 * git
 clone osmocom-bb
 * cd src/host/layer23
 * regular 'autoreconf -fi &&
 ./configure && make'
 
 compile-testing the 'embedded'
 (firmware) part is not possible easily in
 the current master.  However, as a second
 step, and after the
 libosmocore embedded
 build has run (and it is installed to
 /usr/local/arm-none-eabi), and if you use the
 laforge/remove-libosmocore
 branch in
 OsmocomBB, you should also be able to compile-test the
 firmware using
 
 * git clone osmocom-bb
 * cd
 src/target/firmware && make
 
 There currently is no "make check"
 tests for either the host utilities
 or the
 firmware, and of course we have no clue if the resulting
 binaries
 will do anything useful on an
 actual pone [yet!], but I still think the
 two steps above would be very useful to move
 ahead, and to unify the
 patch
 submission/review/verification/approval/merge process in
 gerrit
 with what we have established for the
 network-side projects like OsmoBTS
 & co.
 
 Regards,
     Harald
 
 -- 
 - Harald Welte <laforge at gnumonks.org> 
          http://laforge.gnumonks.org/
 ============================================================================
 "Privacy in residential applications is a
 desirable marketing option."
      
                                        
     (ETSI EN 300 175-7 Ch. A6)