> - rslms_recvmsg() frees message if discriminator is not known,
otherwhise it forward it to rslms_rx_rll().
> - rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does
not free it when RLL message type is unknown.
it seems that the message is freed by the receiving layer (or function),
but i cannot understand why layer2_read() in main.c does it after
calling l1ctl_recv.
hi,
1) thanx for that info. i can see that you tried running it...
2) i have not checked it. i hope that msg->l3h points to l2 pseudo header.
3) before fixing that, i need to have an issue solved:
two approaches to free a message, if it passes a layer border?
a) the sending layer frees the message after calling the other layer.
b) the receiving layer frees the message.
i prefer the second approach, because the message can be queued by the receiving layer without duplicating it. but if i read lapdm.c, i cannot figure out what approach is ment to be used:
- rslms_recvmsg() frees message if discriminator is not known, otherwhise it forward it to rslms_rx_rll().
- rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does not free it when RLL message type is unknown.
this issue must be solved soon, i think.
thanx for looking at it,
andreas
-----Ursprüngliche Nachricht-----
Von: Sylvain Munaut [mailto:246tnt@gmail.com]
Gesendet: Montag, 26. April 2010 15:22
An: Andreas.Eversberg
Cc: baseband-devel(a)lists.osmocom.org
Betreff: Re: Layer 3 status
Hi,
> i will start testing it tonight and hope to get results soon.
Here's a few bug reports
Sorry, there are no 'proper' fix or patches for them, I just worked
around them with ugly hacks see if I could get up to LOCATION UPDATE
REQUEST, then it was kinda late ... I hope just pointing them out will
help you a bit anyway.
1) Typo in src/host/layer23/src/gsm322.c -> gsm322_a_sel_first_plmn
/* if no PLMN in list */
- if (plmn_first) {
+ if (!plmn_first) {
2) BCCH message don't have the same header.
See in src/host/layer23/src/gsm48_rr.c in gsm48_rr_unit_data_ind
struct gsm48_hdr *gh = msgb_l3(msg);
But in BCCH some message don't have this header and have a 'L2 pseudo
length' field ...
3) You do a msgb_free on messages in , but the layer 1 will actually
have freed those message already.
See src/host/layer23/src/main.c in layer2_read(struct bsc_fd *fd)
l1ctl_recv((struct osmocom_ms *) fd->data, msg);
msgb_free(msg); // <======
Sylvain
hi,
i like to give a short update about the current layer 3 development.
everything compiles, but is not tested and debugged yet. it is divided
into five processes:
- radio ressource
this process is partly complete. it implements functions to establish
radio ressource connection. especially handover and release/abort is not
implemented, but will follow soon. most things here depend on services
of the radio part. as the radio part gets more and more functionality,
the radio ressource can be more and more completed.
- mobility management
this process is complete. it also implements the location update
process.
- call control
this process is complete. the MNCC interface of the call control is
almost identical to the openbsc. therefore i would suggest to merge both
"mncc.h" header files and put them into osmocore. currently there is a
minimal application in mnccms.c which rejects any call. (any MS must at
least do this.) later, a small telephone application could be used.
- cell selection
this process is complete. it does not do any measurements on the radio
part for cell (re-)selection. what it does is taking the results and
storing them in a structure. the structure is then used for selecting a
cell. it also controls the frequency used by the radio part.
- PLMN selection
this process is complete. but the manual cell selection requires a user
interface, which does not yet exist. it uses informations from cell
selection process to select available networks.
the term 'complete' refers only to basic call/data service. there is no
VGCS, VBS, multislot, GPRS, SoSLA support. since there is no interface
to the SIM card process (reading of data / storing data), there is just
a comment in the source code whenever data has to be transferred from/to
the SIM. also some special things, like NCC or cell priorization may be
missing.
i will start testing it tonight and hope to get results soon.
regards,
andreas
Hello Sylvain,
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
> When you look deeper into the call, there is the PLL setup that is done
> even earlier, to ensure that it's finished by that 'start' time.
The earlier versions I refer to did no yet switch RX/TX for each burst,
they used to switch after four burst were received/transmitted. In those
versions only the ABB windows was used with the TPU, however we had the
same situation because the code till enabling the TPU took longer than
the "AT" value.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sylvain,
On Sun, 25 Apr 2010 15:16:48 +0000, 246tnt(a)gmail.com wrote:
>
> * For RX it always worked for TS=0 because in l1s_rx_win_ctrl we put the
> first command AT(DSP_SETUP_TIME - 100) ... which when you do the modulo
> 5000 is somewhere around 4944. So when we start executing the TPU scenario
> in the interrupt handler, that first AT command will force to wait almost
> an entire frame and the rx window will be properly placed in the next frame.
To be true, I don't know where the "- 100" in the recent versions come
from. In earlier version the actual AT time was 54 (DSP_SETUP_TIME -
TSP_DELAY - 6). This is about 50 us. However we had the same situation
(actual processing happens in the next frame) because the time to
execute the code after the interrupt occured till the TPU was
enabled took a little bit more than those 50 us. Probably the
code has changed in recent versions so that it tooks less than
those 50 us and "- 100" is needed.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
as this has been a quite weird bug so far, and Sylvain now seems to have
run into some related problems when trying to make a SDCCH8 on TS1 work,
I'll elaborate a bit more on it.
Before commit 0e9d250407f589cff312adc6c9e2c83f6af37de5, what happened was as
follows:
1) The time between the TDMA interrupt happening and starting to execute
l1_sync() and actually being able to configure the TPU window and tell the
DSP what to do was too short for performing the scheduled work in the
very same TDMA frame.
2) As a result, the actions that we thought were performed in the same TDMA
were actually performed one TDMA later. Somehow we must have had another
off-by-one error and thus the two errors compensated themselves in most
cases, particularly for Rx
3) When trying to send, we hand a MAC BLOCK of 23 bytes to the DSP, after
which the DSP has to do the FEC, Fire CRC, burst spreading, etc -
before being able to generate the bits for the furst burst. Those
bits then get sent over the TSP to the ABB (into its burst buffer),
from where they are sent based on TPU signals.
So what happened is that the data of the first burst was not in the
burst buffer yet, and the TPU signals triggered sending the last burst
of the previous MAC block, rather than the first burst of the current.
This is why Dieter added the
> tpu_enq_at(5000 - 10); /* TPU_CLOCK_RANGE - EPSILON_SYNC */
to l1s_tx_win_ctrl(), thereby delaying the TPU signal generation by one
TDMA frame. At that time, the DSP has by long finished writing the new burst
bits in to the ABB burst buffer, and we can transmit the correct burst data.
I personally believe it would be better to simply move the TDMA interrupt a bit
more ahead. Rather than occurring immediately before TS0, we could set SYNCHRO
in a way that it occurs at a defined point in time still quite a bit into TS7.
In this case we hopefully have enough time for the DSP to be able to transmit
in TS0, making the timing sequence easier to understand.
Hope that helps to explain...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
I've playing for a while with the buzzer & PWT registers and I'm able to
hear 'sound' according to the frequencies supported. The thing I can't
not understand well is the relation between the PWT (pulse width tones)
and the PWL (pulse width light), if exists:
A) After loading some frequency into the PWT, set the volume and hear
the it, if I change PWT to BU in the ASIC_CONF_REG, backlight intensity
changes and sound stops.
B) With LT output selected in the ASIC_CONF_REG instead of PWL, changes
over the PWT registers produce nothing.
Hi,
I was reading the bl_mode_pwl function at backlight.c and found
that PWL_CTRL is being written at 0xfffe8002 (0xfffe8000 + 2)
which doesn't map to any known reg. According to the second datasheet
PWL_CTRL (Control Register (PWL_CTRL_REG) (Read / Write)) is located at
0xfffe8001.
maybe i'm wrong?
regards,
emerson.
Hi!
As you can see, there is not really that much progress throughout the last 2
weeks or so. Dieter and myself were the only two who actually looked at how
to driver the DSP, TPU and RF hardware, write the drivers for it and the
existing layer1 code. Now we're both busy with other (paid) work, and
the project almost seems stuck.
I would like to see this change. I'm quite sure there are some other folks
on this list who would be interested in diving in those lower layer bits
of the system. However, I also understand there is not all too much that
can be done without running your own non-hopping BTS (as we don't do frequency
hopping at the moment). So a working OpenBTS, OpenBSC setup or something
like a CMD55 or Racal 6103 are a precondition.
Nonetheless, a number of people on this list have access to those devices.
I'd like to encourage some other people to also look at this and remove the
dependence on Dieter and myself in that area.
Furthermore, members of the IRC channel have certainly noticed the growing
interest in a potential port to the Mediatek chipset based devicees. Mediatek
is churning out more than 95 million chipsets every quarter, so there is plenty
of phones around.
The data sheets, reference schematics and other training materials can easily
be found on a lot of chinese developer websites - as is the Mediatek SDK.
However, the critical layer1 and DSP API part is only provided in object code,
and the documentation does not document it.
Still I believe it is feasible. So if you want to stay out of the GSM part,
feel like the Calypso is too boring for you: Why not work on getting a minimal
custom software image for the MT622x running, including bootloader support,
keypad/touchscreen and graphics output? If that is done by the wider
community, the so-called experts can focus on looking at the GSM side of things
once they have time.
Even on the Calypso there are many tasks that still need to be finished,
including battery charging, power management, file system, SIM Card API,
etc.
If you know somebody who understands C development for microcontrollers and
wants to help building the worlds first Free Software GSM baseband chipset
software, please motivate them to join. We can really need every helping hand
we get.
Happy hacking,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
