Project

General

Profile

Actions

Feature #1461

open

include some version information / negotiation in the L1CTL protocol

Added by laforge about 8 years ago. Updated over 2 years ago.

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

60%

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 protocolNewlaforge

Actions
Related to OsmocomBB - Feature #5815: mobile: compose Bearer Capability IE depending on PHY capabilities and GAPK codec supportNew12/06/2022

Actions
Actions #1

Updated by laforge about 8 years ago

  • Assignee deleted (laforge)
Actions #2

Updated by fixeria about 7 years ago

  • Assignee set to fixeria
  • % Done changed from 0 to 30
Actions #3

Updated by fixeria about 7 years 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?

Actions #4

Updated by laforge about 7 years 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
Actions #5

Updated by fixeria almost 7 years ago

  • Status changed from New to Stalled
Actions #6

Updated by fixeria almost 6 years ago

  • Status changed from Stalled to In Progress
Actions #7

Updated by fixeria almost 6 years ago

  • Status changed from In Progress to Stalled

Switched to USSD related work...

Actions #8

Updated by fixeria over 5 years ago

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

Updated by fixeria over 5 years 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...

Actions #10

Updated by fixeria over 5 years ago

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

Updated by fixeria over 5 years ago

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

Updated by fixeria over 5 years 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.

Actions #13

Updated by fixeria over 5 years ago

  • Target version set to Improvement of the higher layers of OsmocomBB
Actions #14

Updated by ptrkrysik over 4 years ago

  • Target version deleted (Improvement of the higher layers of OsmocomBB)
Actions #15

Updated by fixeria over 2 years ago

  • Status changed from Feedback to Stalled
Actions #16

Updated by fixeria over 1 year ago

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

Updated by fixeria over 1 year ago

  • Related to Feature #5815: mobile: compose Bearer Capability IE depending on PHY capabilities and GAPK codec support added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)