Project

General

Profile

Feature #1461

include some version information / negotiation in the L1CTL protocol

Added by laforge over 2 years ago. Updated 30 days ago.

Status:
Feedback
Priority:
High
Assignee:
Category:
OsmocomBB Firmware
Target version:
-
Start date:
Due date:
% Done:

60%

Estimated time:
Resolution:
Spec Reference:

Description

The host software should have a way to determine the firmware build/version, as well as the enabled features (TX support or not, burst_ind, ...).


Related issues

Related to SIMtrace 2 - Feature #1460: include some version information / negotiation in the USB protocolNew

Blocks OsmocomBB - Feature #3400: mobile: implement GAPK based audio capture / playback (via ALSA)New2018-07-17

History

#1 Updated by laforge over 2 years ago

  • Assignee deleted (laforge)

#2 Updated by fixeria over 1 year ago

  • Assignee set to fixeria
  • % Done changed from 0 to 30

#3 Updated by fixeria over 1 year ago

The following information we can provide to layer23 applications:

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));

Any ideas? Maybe something else?

#4 Updated by laforge over 1 year ago

On Sun, Mar 05, 2017 at 08:08:08AM +0000, fixeria [REDMINE] wrote:

The following information we can provide to layer23 applications:

pleae provide some more background on the usage of those fields

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;

is it well-defined what the above fields are used for? Are we sure that
uint8_t is sufficient for those? Are all of the values directly read
from hardware? If so, where from?

/* Supported features */
uint8_t tx_support;
uint8_t sim_support;
uint8_t burst_ind_support;
uint8_t transceiver_support;

I would structure this in a way that it can be extended in the future.
One option would be to do something similar to the 'classmark' feature
on GSM, where the phone indicates a variable-length bitmask to the
network, and new bits can be added at the end. Old software will simply
only read the bits it understands and ignore the bits at the end. As we
don't care about the size of the structure, we could do it with bytes
instead of bits, but that's a matter of taste.

so generally I would counter-propose:

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));

so then the code can have a variable-length list of features, and you
can add more over time, with forward/backward compatibility

Any ideas? Maybe something else?

I would also include the information about
  • build target (e88/e99/...)
  • git version of firmware compile
  • whether code is running from flash or ram

#5 Updated by fixeria over 1 year ago

  • Status changed from New to Stalled

#6 Updated by fixeria 3 months ago

  • Status changed from Stalled to In Progress

#7 Updated by fixeria 2 months ago

  • Status changed from In Progress to Stalled

Switched to USSD related work...

#8 Updated by fixeria about 1 month ago

  • Related to Feature #1460: include some version information / negotiation in the USB protocol added

#9 Updated by fixeria about 1 month ago

As OsmocomBB is not the only project, for which it would be great to have some info / caps negotiation,
I think we can share some helper functions in libosmocore to avoid code duplication. Having TVL-based
API for info negotiation, and bitvec-based (one bit is one feature) API for capabilities negotiation on top
of msgb API looks fine for me...

#10 Updated by fixeria about 1 month ago

  • Blocks Feature #3400: mobile: implement GAPK based audio capture / playback (via ALSA) added

#11 Updated by fixeria 30 days ago

  • Category changed from OsmocomBB Layer 1 (Coding) to OsmocomBB Firmware
  • Status changed from Stalled to In Progress

#12 Updated by fixeria 30 days ago

  • Status changed from In Progress to Feedback
  • % Done changed from 30 to 60

The initial version of helper functions has been submitted:

https://gerrit.osmocom.org/10034/

I will be happy to get some feedback.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)