Hi,
for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR).
I could envision we have:
* A simple build shell script to build/install everything
* A script to update (and tag) the default.xml to make new releases available.
How to use it (if repo is installed):
repo init -u git://git.osmocom.org/osmocom-cellular-manifest
repo sync
./build_all.sh --prefix=/opt/cellular
aand on a new release
repo sync
./build_all.sh ...
ideas? comments?
holger
default.xml:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote fetch="git://git.osmocom.org" review="gerrit.osmocom.org" name="osmocom"/>
<default revision="refs/heads/master" remote="osmocom"/>
<!-- base libraries -->
<project name="libosmocore" revision="9e83c3d5ca64428befe74e5aad61bd84bccaf309"/>
<project name="libosmo-abis" revision="bf7976c0b0076410ad1bd67061dd18d0f33a7f43"/>
<project name="libosmo-netif" revision="c108c9db969c4d4abaccc88419b4ac0c44957365"/>
<project name="libsmpp34" revision="cc0bcd6bc051d5ccaf32cdbbc28f073369900857"/>
<project name="libosmo-sccp" revision="57d0449d4ed5d82050c52551c8ad6195db38fdf1"/>
<!-- RAN -->
<project name="osmo-trx" revision="de116e90c03c534fa4b51ef40dfd2bb9e843c86e"/>
<project name="osmo-bts" revision="25742a5929edecc545a4fc254f678cc834f8c3b3"/>
<project name="osmo-pcu" revision="e6d26ec09c2bcd2126416a58cb23af27318ec67e"/>
<project name="osmo-iuh" revision="46fea15afc38fb995baf4100f4de1d6a3565899f"/>
<project name="openggsn" revision="19e19e3609508d121ba46c165e5ed1502a3cf9da"/>
<project name="openbsc" revision="d75f11e6f26a50c11f73625de5c0833971900cde"/>
<project name="osmo-sip-connector" revision="417f2542163edfe8ac8729918e2452dc7787a3d7"/>
<!-- Core -->
<project name="osmo-hlr" revision="743cf42ac5dfa2661317e73f70b204bde7450ff2"/>
<!-- Misc -->
<project name="osmo-gsm-manuals" revision="4b593a2259a107211489940b8b59f44219e73b2d"/>
<!-- Copying a build script to the top level directory -->
<project name="osmo-ci" revision="e72f35cfa9969e52d0018ba4661f4519519c39ba">
<linkfile src="build/build.sh" dest="build.sh"/>
</project>
<project name="python/osmo-python-tests" path="osmo-python-tests" revision="baa6f12260c383f40a477b71743b16940c50e5aa"/>
</manifest>
Hi Tomas,
I again have a question related to your SSE accelerated Viterbi
decoder, and I hope it's the last issue, which prevents us from
finishing this work. In short, SSE based implementation provides
one-byte different decoding result for SCH transcoding test. So,
the whole GSM 05.03 coding test fails.
I have done some debugging, and would like to share some results.
Have a look at the tests/coding/test_sch(), which first encodes
a L3 packet into ubits and sbits, then some bits are getting
destroyed, then the gsm0503_sch_decode() is being called to get
decoded bytes back, and finally decoded bytes are being compared
with original bytes.
As long as encoder implementation is not covered by SSE code,
it works as before. But SSE accelerated decoder outputs one-byte
different result in case of SCH:
int gsm0503_sch_decode(uint8_t *sb_info, sbit_t *burst)
{
ubit_t conv[35];
int rv;
osmo_conv_decode(&gsm0503_sch, burst, conv);
rv = osmo_crc16gen_check_bits(&gsm0503_sch_crc10,
conv, 25, conv + 25);
if (rv)
return -1;
// ...
}
// Original implementation
ubit_t conv[35] = {
0x01 0x01 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00
};
// Accelerated implementation
ubit_t conv[35] = {
0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00
};
As you can see, the conv[3] isn't the same in both cases. So,
at the next step the osmo_crc16gen_check_bits() returns -1.
Latest version of this change:
https://gerrit.osmocom.org/#/c/2454/
Do you have any ideas? Despite SCH decoding isn't required on
BTS side, the problem may be more global, than the test shows.
With best regards,
Vadim Yanitskiy.
