baseband-devel

baseband-devel@lists.osmocom.org

2 participants
2003 discussions

wiki-access/todo-list
by Wolfram Sang 09 Mar '10

09 Mar '10

Hello, I couldn't find any possibility to register for a trac-account. I assume it is intentional that only the maintainers may change content (I could see reasons for that)? If so, is there a chance to keep the todo-list updated? I know by now that there is already work ongoing for the C155-display driver. I just became unsure which other topics may already been worked on. Kind regards, Wolfram PS: One for the news section maybe? http://www.pro-linux.de/NB3/news/1/15336/1,osmocombb-will-mobilfunk-mit-fre…

3 5

timer_list implementation
by Harald Welte 09 Mar '10

09 Mar '10

hi! we now have a 'struct timer_list' API, its use is similar to that of the linux kernel (and openbsc). The caller (e.g. your driver/app) allocates a 'struct timer_list', sets the 'cb' function pointer to a callback function, and then schedules the timer with 'schedule_timer(&my_struct_tm, 600) for expiration in e.g. 600ms from now. Once the timer expires, it will call the callback. There's also an 'unsigned long' argument that you can pass along. Calling the timer expiration routines happens by calling update_timers() from the while (1) loop in the main program. This will of course change once we have a scheduler and tasks. Cheers, 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)

5 10

AW: status layer 3
by Andreas.Eversberg 09 Mar '10

09 Mar '10

> L3 sends RSL RLL ESTABLISH REQUEST with LOC UPD REQ as L3_INFO > L2 converts this in SABM with LOC UPD REQ as payload > L1 sends the packet to the GSM network > L1 receives response from the GSM network > L2 generates RSL RLL ESTABLISH CONFIRM to L3 hi, just to see if i understand it right, here is my view of how it should work: (for reference, see Fig. A.4 in GSM 04.07 in the appendix A.) mobility management layer requires to send an location update, so it does the following things happen: - a msgb is created with payload, large enough for LOC UPD REQ, and a headroom to encapsulate it into other messages... - LOC UPD REQ is assembled by mobility management layer - the msbg is "pushed" to add radio ressource header in front of it - the radio ressource primitive RR EST REQ is written to radio ressource header - the msgb is now transferred using a function call to radio ressource layer - the radio ressource routes the message according to the state and the primitive to the appropiate handler of this message. (state machine) - there the msgb is "pulled" to remove that header - the handler of "RR EST REQ message in IDLE mode" stores the msbg until an IMM ASS is received, and starts channel request procedure... ... - when handling the IMM ASS, the radio ressource layer takes the stored msgb and pushes the RSL RLL header in front of it - the RSL RLL header gets informations about channel to establish, and the RSL EST REQ primitive is set - the msgb is sent down from radio ressource layer to layer 2, in this case the RSLms layer, using a function call. (RSL EST REQ represents the DL-ESTABLISH REQUEST primitive) while the message is walking from radio ressource layer down to layer 1, the primitives for inter-layer communication are added by the sending layer and removed by the receiving layer. is this procedure correct? (of course, more things are done at radio ressource and mobility management layers in the procedure above, but i just wanted to explain what happens to the msgb. regards, andreas

2 1

AW: status layer 3
by Andreas.Eversberg 08 Mar '10

08 Mar '10

hi, my last mail was written yesterday and somehow sent today. meanwhile i decided to work with GIT for the following reasons: - working with others parallel on L3 - faster solving of issues. solving before finishing the code. - backup (even loss of one weekend's work would be a great loss of motivation) i will try the GIT tonight... anyway here is my first issue: the messages between layer 3 (radio ressource) and layer 2 have primitives starting with DL_*. e.g. DL_RANDOM_ACCESS_REQ is used to send a CHANNEL REQUEST on the RACH. and DL_ESTABLISH_REQ is used to establish a layer 2 link on SDCCH or TCH. both messages carry layer 3 messages, like CHANNEL REQUEST or LOCATION UPDATE REQUEST. using msgb between layer 2 and 3 is not enough, because i need to exchange additional informations with layer 2. these are the primitives themselves, and in case of DL_ESTABLISH_REQ the channel information for frequency, channel type, slot, ect. my current solution is to use a structure with primitive type and all additional informations and a pointer to the attached layer 3 message, if there is actually one message. (not yet immplemented, but already implemented at mncc interface in openbsc.) to prevent function call loops, i use a queue in the upward direction, so the structure with the message is copied into a msbg and added to the queue. (remember that this message may carry another layer 3 message) is there a better (simpler) way? regards, andreas

2 1

AW: status layer 3
by Andreas.Eversberg 08 Mar '10

08 Mar '10

hi harald, as i am still working on RR MM and CC layer, it seems to be more complicated as i thought. remember all the messages in 04.08? but most problem is that i must first understand it all. i get more and more knowledge about it while reading it. i started implementing some parts, but most parts i do not understand yet. as i know from earlier project, it requires exact knowledge of every bit to do it right. when i am finished, i will tell you as soon as possible, but i think it takes some more weeks. anyway, there will be many issues then. as i can see, there the layer 2 and layer 1 will also be not that easy too. e.g. layer 2 must process channel descriptions to connect to the right channel and the right configurations and mode. also when i am finished, i will need to solve some coding issues, like message flow, queueing (to prevent message loops), and structures for subscriber data, telephone settings and system informations. as soon i am finished, i will make a list of remaining unsolved issues. and finally gsm 03.22 (selecting and changing cells) must also wants to be implemented. if you like to be aware of what i am doing, just watch my code base. it is live, so every time i do a write, it will be available at: http://home.eversberg.eu/alpha3/ regards, andreas

2 1

OsmocomBB update summary
by Harald Welte 07 Mar '10

07 Mar '10

Hi! Today, there have been quite a number of possibly intrusive changes in the repository. A quick summary: * prom's new makefile voodoo has been merged for the 'firmware' directory, this means we now have proper dependency tracking in our builds, as well as support for multiple board builds * the compiled elf/map/bin/... files are now in board/compal_{e88,e99}, rather than in the main directory. * the firmware now uses the real libosmocore (and its linuxlist, msgb,...) code. No more code duplication, and one step closer to easy migration of the layer23 code into the firmware at some later day. * lots of minor changes here and there have been introduced to reduce number of compiler warnings. * l1ctl messages (L1 <-> L2/L3) communication has changed a little bit, it now includes only the frame number and not a full 'struct gsm_time'. This is important for anyone who has his own ocde to talk to the L1! I hope this was the last time we've had such an amount of changes, especially to the build system. Regards, 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)

1 0

C155 display driver
by Harald Welte 07 Mar '10

07 Mar '10

Hi Steve, I have now partially merged your C155 display driver. Partial, since I only merged those parts that didn't break the build for C123. So what needs to be done soon: * support multipe 'boards' in our Makefile magic, producing NR_BOARDS * NR_APPS images as a result. * merge those parts that are identical between board_e88 and board_e99 and create something like a calypso_init() function, keeping only board specific bits in the board_init() * introduce some "lcd_puts()" macro that is defined to either of the two display drivers, depending on the board that we're building for. If anyone is posting patches (or a git branch) for that, I'd be happy to merge them. Later on, I want a LCD abstraction layer that hides the details from the apps. The app should not have to care about color/monochrome, or the fact that the X/Y coordinates seem to be inverted between the displays. I personally have no interest in doing that, as GSM related work has much higher priority to me. I hope somebody in the community will take care of the task. Thanks in advance! Regards, 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)

1 0

Re: status layer 3
by Harald Welte 05 Mar '10

05 Mar '10

Hi Andreas, I'm going to pick up your questions as found in your preliminary http://home.eversberg.eu/alpha3/ code. I took the liberty of posting to the ML, as other people will definitely be interested in this, too. 1) why is layer2 a socket client? because we want to develop layer2 + layer3 + everything above on the PC first, while keeping the L1 on the phone. This makes debugging much easier. Later we will simply move the code to the phone and run it in one or multiple tasks of the operating system, replacing sercomm + unix socket with message queues. 2) where is layer3 to go? I think we can directly put it into the layer2 program, but try to keep a clean seperation between l2 and l3, using the REQUEST/RESPONSE/INDICATION primitives. 3) where should the app (layer4) go? library or console? it should live on top of the l23 stack, preferrably as its own program. There is a lot of sense for having the application (UI) as its own process/thread, and the stack in its process/thread. 4) Is the TLV parser buffer-overflow safe? TLV parser (libosmocore) is not buffer-overflow safe, patches are appreciated. 5) classmark1 lsb/msb twisted: I have no idea :) 6) lchan/ms mapping. I don't have a clear idea on this either. I'm not so sure if the 'lchan' concept makes much sense in a phone at all. A phone typically only uses one dedicated channel at any given point - with corner cases in the event of a handover, where we 'switch back' to the old channel if establishing the new channel fails. 7) ms instantiation for multiple devices I think this is not really an important issue at the moment. If there are multiple phones, there should be multiple instances (processes) of the layer23 stack. A normal application would also exist 1:1 for each stack instance. If you think of some PBX application, than I also think it is easier to have one instance (process or thread) of the stack for each phone. After all, the primary target for us is to make layer2+3 work in a phone, and there it will definitely be one instance for one phone. One additional comment: Please make sure that the common/shared code between OpenBSC and your Layer3 does get moved into libosmocore. I'm thinking particularly abotu code for parsing and generating the various IE's. We don't want to keep multiple implementations around... Thanks again for all your help, 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)

2 2

OsmocomBB developer meeting 2010-03-06 8pm CCCB
by Harald Welte 04 Mar '10

04 Mar '10

Hi! There will be an informal meeting of OsmocomBB hackers at the Berlin CCC (http://berlin.ccc.de/) on Saturday, 2010-03-06 at 8pm local time. Prom and myself will be there, most likely also dexter and tec. If you're local, feel free to join. There's no formal agenda, we just like to meet one more time before I'll disappear to Taiwan for quite some time. Regards, 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)

1 0

GSMTAP / layer23 / wireshark updates
by Harald Welte 04 Mar '10

04 Mar '10

Hi! I've improved the layer23 gsmtap support to add support for * uplink frames, sent by layer23 to L1 * properly support dedicated channels with LAPDm * allow the user to specify the GSMTAP destination IP address In order to use the new features, you need to 1) use the new gsmtap.patch for wireshark 2) use the '-i dstip' option of layer23, as the default is now to NOT generate GSMTAP UDP Packets I'm attaching a screen-shot showing the wireshark decode of the LOC UPD REQ generated by layer23. As you can see from the packet list, the BTS responds with the UA packet containing the same LOC UPD REQ as part of the contention resolution in LAPDm, just as expected. Cheers, 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)

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel