octasic build failure / header versions

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Fri Sep 9 01:18:03 UTC 2016


On Wed, Sep 07, 2016 at 12:44:37PM +0200, Neels Hofmeyr wrote:
> osmo-bts included a struct member not present anywhere in octphy-2g-headers.
> 
> https://gerrit.osmocom.org/820
> https://gerrit.osmocom.org/821
> 
> On our test setup at sysmocom, I found a version of the headers called
> OCTSDR-2G-02.05.00-B780-DEBUG that includes this struct member, but those
> headers have proprietary licensing. Also, the current version apparently is
> 2.07, while the one with the unknown struct header seems to be older: 2.05. So
> it looks like the usCentreArfcn item has been removed in a newer version, even
> though it looks really useful to me.
> 
> It would be good to resolve this confusion, probably as soon as Max is back
> from vacation (Max is the author of the reverted commits).

The commit relates to the development of Multi-TRX support for OCTPHY.
The fact that no GPL-compatible headers had been provided is probably an
oversight and it would be best to simply ask Octasic to provide them.

As there are the master (single-TRX) and multi-TRX PHY versions out
there in parallel, it would be best if we can compile against both of
them, possibly by checking for the given struct members from autoconf
and then adapting accordingly.

The same goes for other related new additions, like EGPRS capabilities
in the PHY.

> In the most recent version, a #define naming has changed.
> In https://gerrit.osmocom.org/822 Holger asks:
> 
> > Do we have any precedence of using #if for version checks? You can
> > use #ifdef for both of them to support old and new headers?
> 
> We could use a check like
> 
> #if cOCTVC1_HW_VERSION_MAJOR <=2 && cOCTVC1_HW_VERSION_MINOR < 7

Yes, and we should.  As much as our jenkins should try to compile
osmo-bts against various different (at least recent) PHY header
releases, both 'stable' as well as those with multi-TRX and/or EGPRS
features.

Reards,
	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)



More information about the OpenBSC mailing list