Hi all!
In order to avoid the most common problems, I propose exporting something like a feature bitmask on the L1CTL, i.e.
* L1CTL user code (layer23) can send a L1CTL_GET_FEAT_REQ request * laye1 in the phone sends a L1CTL_GET_FEAT_RESP with all the bits set to 1 for the features it supports * L1CTL user code (layer23) can then check if all the features it needs are supported by the L1. IF not, it can simply abort or print a warning to the user.
We can simply extend the size of the bitmask over time if we need more bits.
Obvious bits I would consider are:
- is this firmware compiled with TX support? - does this firmware contain a SIM reader driver? - does this firmware support BURST_IND?
Maybe we could also include a static header containing a compile timestamp or the git date/revision that the firmware was built, as well as a name of the board.
Now I know, nice idea, who will implement it? I currently have othe priorities, but if somebody lurking on this list is looking for a relatively simple way to contribute back to the project (without knowing anything about GSM!) this might be something useful you could do.
Thanks in advance, Harald
Hi,
On Mon, Jan 17, 2011 at 11:00:56PM +0100, Holger Hans Peter Freyther wrote:
Obvious bits I would consider are:
- is this firmware compiled with TX support?
this could become a runtime feature as well? Would we set introduce a SET_FEAT_REQ?
it could - but I think just to make a point and avoid any accidents, I would like to keep an easy way how people can build (and use) firmware that will absolutely not transmit under any circumstance.
So I think it should remain a GET request for the time being,
Hi
Am 18.01.2011 um 10:51 schrieb Harald Welte:
it could - but I think just to make a point and avoid any accidents, I would like to keep an easy way how people can build (and use) firmware that will absolutely not transmit under any circumstance.
So I think it should remain a GET request for the time being,
Probably we should allow to switch TX off if it was on, but not vice versa. This way some apps which are not designed for a TX enabled firmware could switch it off.
Matthias
Harald Welte wrote:
In order to avoid the most common problems, I propose exporting something like a feature bitmask on the L1CTL, i.e.
- L1CTL user code (layer23) can send a L1CTL_GET_FEAT_REQ request
- laye1 in the phone sends a L1CTL_GET_FEAT_RESP with all the bits set to 1 for the features it supports
- L1CTL user code (layer23) can then check if all the features it needs are supported by the L1. IF not, it can simply abort or print a warning to the user.
Any point in using names for features, rather than bits?
Obvious bits I would consider are:
- is this firmware compiled with TX support?
- does this firmware contain a SIM reader driver?
- does this firmware support BURST_IND?
Maybe we could also include a static header containing a compile timestamp or the git date/revision that the firmware was built, as well as a name of the board.
Yes, all good stuff.
//Peter
Hi Peter,
On Tue, Jan 18, 2011 at 11:17:13AM +0100, Peter Stuge wrote:
Harald Welte wrote:
In order to avoid the most common problems, I propose exporting something like a feature bitmask on the L1CTL, i.e.
- L1CTL user code (layer23) can send a L1CTL_GET_FEAT_REQ request
- laye1 in the phone sends a L1CTL_GET_FEAT_RESP with all the bits set to 1 for the features it supports
- L1CTL user code (layer23) can then check if all the features it needs are supported by the L1. IF not, it can simply abort or print a warning to the user.
Any point in using names for features, rather than bits?
well, simply define an enum for the bits in a common header file. I really don't want to pass around strings on the L1CTL interface, it just feels wrong ;)
baseband-devel@lists.osmocom.org
-
Harald Welte -
Holger Hans Peter Freyther -
Peter Stuge -
Thatist