https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-02-21T16:34:54ZOpen Source Mobile CommunicationsOsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=9722016-02-21T16:34:54Zlaforge
<ul><li><strong>Assignee</strong> deleted (<del><i>laforge</i></del>)</li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=32442017-03-05T07:18:51Zfixeria
<ul><li><strong>Assignee</strong> set to <i>fixeria</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>30</i></li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=32452017-03-05T08:08:08Zfixeria
<ul></ul><p>The following information we can provide to layer23 applications:</p>
<pre>
struct l1ctl_l1_info_ind {
/* HW info */
uint8_t hw_dev_id;
uint8_t hw_dev_ver;
uint8_t hw_dev_arm_ver;
uint8_t hw_cdsp_ver;
/* Supported features */
uint8_t tx_support;
uint8_t sim_support;
uint8_t burst_ind_support;
uint8_t transceiver_support;
} __attribute__((packed));
</pre>
<p>Any ideas? Maybe something else?</p> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=32472017-03-05T09:36:08Zlaforge
<ul></ul><p>On Sun, Mar 05, 2017 at 08:08:08AM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>The following information we can provide to layer23 applications:</p>
</blockquote>
<p>pleae provide some more background on the usage of those fields</p>
<blockquote>
<p>struct l1ctl_l1_info_ind {<br />/* HW info */<br />uint8_t hw_dev_id;<br />uint8_t hw_dev_ver;<br />uint8_t hw_dev_arm_ver;<br />uint8_t hw_cdsp_ver;</p>
</blockquote>
<p>is it well-defined what the above fields are used for? Are we sure that<br />uint8_t is sufficient for those? Are all of the values directly read<br />from hardware? If so, where from?</p>
<blockquote>
<p>/* Supported features */<br />uint8_t tx_support;<br />uint8_t sim_support;<br />uint8_t burst_ind_support;<br />uint8_t transceiver_support;</p>
</blockquote>
<p>I would structure this in a way that it can be extended in the future.<br />One option would be to do something similar to the 'classmark' feature<br />on GSM, where the phone indicates a variable-length bitmask to the<br />network, and new bits can be added at the end. Old software will simply<br />only read the bits it understands and ignore the bits at the end. As we<br />don't care about the size of the structure, we could do it with bytes<br />instead of bits, but that's a matter of taste.</p>
<p>so generally I would counter-propose:</p>
<pre>
struct l1ctl_l1_info_ind {
/* version of this structure, if we ever have to change it */
uint16_t version;
struct {
uint8_t dev_id;
uint8_t dev_ver;
uint8_t dev_arm_ver;
uint8_t cdsp_ver;
} hw;
struct {
uint16_t len;
uint8_t data[0];
} features;
} __attribute__((packed));
</pre>
<p>so then the code can have a variable-length list of features, and you<br />can add more over time, with forward/backward compatibility</p>
<blockquote>
<p>Any ideas? Maybe something else?</p>
</blockquote>
I would also include the information about
<ul>
<li>build target (e88/e99/...)</li>
<li>git version of firmware compile</li>
<li>whether code is running from flash or ram</li>
</ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=37572017-05-03T08:13:17Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Stalled</i></li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=94452018-05-19T23:58:59Zfixeria
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=98192018-06-10T13:47:45Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul><p>Switched to USSD related work...</p> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=103432018-07-16T23:19:18Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-2 priority-default" href="/issues/1460">Feature #1460</a>: include some version information / negotiation in the USB protocol</i> added</li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=103442018-07-16T23:30:17Zfixeria
<ul></ul><p>As <a class="wiki-page" href="https://osmocom.org/projects/baseband/wiki/OsmocomBB">OsmocomBB</a> is not the only project, for which it would be great to have some info / caps negotiation,<br />I think we can share some helper functions in <a class="wiki-page" href="https://osmocom.org/projects/libosmocore/wiki">libosmocore</a> to avoid code duplication. Having TVL-based<br />API for info negotiation, and bitvec-based (one bit is one feature) API for capabilities negotiation on top<br />of msgb API looks fine for me...</p> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=103452018-07-16T23:30:59Zfixeria
<ul><li><strong>Blocks</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/3400">Feature #3400</a>: mobile: implement GAPK based audio capture / playback (via ALSA)</i> added</li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=103632018-07-17T21:09:04Zfixeria
<ul><li><strong>Category</strong> changed from <i>OsmocomBB Layer 1 (Coding)</i> to <i>OsmocomBB Firmware</i></li><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=103642018-07-18T02:16:20Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>30</i> to <i>60</i></li></ul><p>The initial version of helper functions has been submitted:</p>
<p><a class="external" href="https://gerrit.osmocom.org/10034/">https://gerrit.osmocom.org/10034/</a></p>
<p>I will be happy to get some feedback.</p> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=111132018-09-02T18:43:12Zfixeria
<ul><li><strong>Target version</strong> set to <i>Improvement of the higher layers of OsmocomBB</i></li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=149182019-06-21T11:56:35Zptrkrysik
<ul><li><strong>Target version</strong> deleted (<del><i>Improvement of the higher layers of OsmocomBB</i></del>)</li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=228442021-10-27T22:17:34Zfixeria
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Stalled</i></li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=257402022-12-06T19:39:26Zfixeria
<ul><li><strong>Blocks</strong> deleted (<i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/3400">Feature #3400</a>: mobile: implement GAPK based audio capture / playback (via ALSA)</i>)</li></ul> OsmocomBB - Feature #1461: include some version information / negotiation in the L1CTL protocolhttps://osmocom.org/issues/1461?journal_id=257422022-12-06T19:39:34Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/5815">Feature #5815</a>: mobile: compose Bearer Capability IE depending on PHY capabilities and GAPK codec support</i> added</li></ul>