- baseband-devel - lists.osmocom.org

Re: osmocom on windows
by Dieter Spaar 07 Oct '10

07 Oct '10

On Thu, 7 Oct 2010 02:22:52 -0700 (PDT), "eisencah eisenach" <wbg_1000(a)yahoo.com> wrote: > > I would like to compile the hole thing for windows (change in the osmocore > lib the suport functions - use maybe pipes instead of sockets). What is the whole thing ? The phone firmware has to be compiled by an ARM compiler, and if you use GNU ARM, you need Cygwin anyway. If you want to use a different compiler for the host software, you most certainly have to adjust quite a lot of the source code, expecially when using the Microsoft C compiler. And why use pipes instead of sockets, Windows has sockets. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

4 3

osmocom on windows
by eisencah eisenach 07 Oct '10

07 Oct '10

Hello everybody. I've done my reading on GSM these last months and have a general ideea how it works. I would like to try to run osmocom on Windows (hope don't get stoned for this :) ) I've been going throgh the files and see how interprocess communication is done (between osmocom and osmoload for example). Do you have any recommendation about what to use on windows as the interface between the 2 programs? Has anyone else tried it? Cheers, Mihai.

4 4

Re: OsmocomBB.TCH.
by Marten Christophe 05 Oct '10

05 Oct '10

> > Hello All, > > How can i download the source code for sylvain/testing branch . > to my PC ? > > I just downloaded git://git.osmocom.org/osmocom-bb.git, > but it is not reflecting / having the file addition and modification or > the changes sylvain/testing branch commited one hour before. > > is there any new trunck for this. or other command then git clone git:// > git.osmocom.org/osmocom-bb.git, > > Kind Regards, > > >

8 15

Re: OsmocomBB.TCH.
by Dieter Spaar 05 Oct '10

05 Oct '10

Hello Sylvain, On Mon, 4 Oct 2010 22:13:13 +0200, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > And Dieter's code probably worked on some internal version of the code > that were never even commited on the public tree and he may not even > have any more ... Yes, exactly, this code was never commited. Its main purpose was to get the TCH up and running. BTW, I still do not fully understand what Marten wants to do: - send a TCH ? If yes, with which device, a BTS or a GSM testset like I did with the HP8922 ? If it is the HP8922, this sending of audio data over one the external connectors of the testset also works with a full MOC or MTC, so no need to hack anything. Just use Sylvain's TCH testing branch and perform a MOC or MTC. This of course works with any GSM phone, so no need to use OsmocomBB at all... - something else I have not understand yet which requires just TCH receiving and no signalling ? Or recieve the same TCH on multiple phones ? Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: OsmocomBB.TCH.
by Dieter Spaar 04 Oct '10

04 Oct '10

Hello Nordin, On Mon, 04 Oct 2010 09:43:36 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > Maybe he needs just a simple example how you guys do that. That might > help him to see some logic in the code and can pick it up quickly. Also, > you never know what experience he has, maybe with some help he can help > you back more. But than again, it's all up to your free time, which is > always too short. The code I used when I started to implement the TCH in Layer-1 will no longer work with the current version of OsmocomBB so it is of no help. This means I have to rewrite it and test it to be sure that it works as expected which will take some time, time as you already mentioned, is my free time and this free time is valuable. I have the impression that in this case a quite detailed explanation including a working example is necessary and some hints won't help but only result in more questions. Although it might sound harsh, but knowledge in GSM and being able to read/understand/modify foreign source code is necessary, noone can expect this to learn here by asking the list. If one takes OsmocomBB as it is and registers to a cell and makes a call, the logging output should give a lot of hints what calls to L1CTL have to be done. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

4 4

Re: OsmocomBB.TCH.
by Dieter Spaar 04 Oct '10

04 Oct '10

Hello Marten, First of all please be aware that OsmocomBB is now in a state where it can be used for voice calls without any special tricks so there is no need to tune on the voice traffic of the HP8922 GSM testset, you can use the GSM testset as a normal basestation. On Wed, 29 Sep 2010 23:00:44 +0000, "Marten Christophe" <technosabby(a)gmail.com> wrote: > > Q.1) i learned from wiki how to change ARFCN from Layer on application by > using below command, but how to tune right TS ? > > ./layer23 -a 871 -i 127.0.0.1 For my inital TCH testing I did not use Layer23 at all, I only used Layer1 in the phone with special test code using a fixed ARFCN. > Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time > Slot, will i be able to listen what so ever broadcasting from HP8922 from > C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Yes. > Q.3) what command and interface will be used to enter the frequency hoping > parameter, in case i will use FH option? to tune OsmocomBB l1CTL You have to write your one code if you want to do this without Signalling beeing involved. > Q.4) How to enter Minimalistic L1 interface, what is interface available to > insert theses command to layer1 You can use the L1CTL API to setup a TCH with your own code, but its probably easier to setup the TCH with signalling (either MOC or MTC), this way you don't need to modify the code and still get the TCH running. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

5 8

OsmocomBB.TCH.
by Marten Christophe 30 Sep '10

30 Sep '10

Hello, Thanks u all this gr8.. work .. forgive me for my little novice question.. most probably goes to Mr. Deiter.. but any one from list be kind enough help me from list.. I'm pretty new to Osmocombb i made a setup as advised on *Sun, 01 Aug 2010* blog. with hp8922. ===Q=== " You just "tune" to the right ARFCN and time slot (I don't use hopping during testing) and see that you get your code running." ===UQ== Q.1) i learned from wiki how to change ARFCN from Layer on application by using below command, but how to tune right TS ? ./layer23 -a 871 -i 127.0.0.1 Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time Slot, will i be able to listen what so ever broadcasting from HP8922 from C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Q.3) what command and interface will be used to enter the frequency hoping parameter, in case i will use FH option? to tune OsmocomBB l1CTL Q.4) How to enter Minimalistic L1 interface, what is interface available to insert theses command to layer1 DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND thanks , Martin

1 2

(no subject)
by Marten Christophe 30 Sep '10

30 Sep '10

Hello, Thanks u all this gr8.. work .. forgive me for my little novice question.. most probably goes to Mr. Deiter.. but any one from list be kind enough help me from list.. I'm pretty new to Osmocombb i made a setup as advised on Sun, 01 Aug 2010 blog. with hp8922. ===Q=== " You just "tune" to the right ARFCN and time slot (I don't use hopping during testing) and see that you get your code running." ===UQ== Q.1) i learned from wiki how to change ARFCN from Layer on application by using below command, but how to tune right TS ? ./layer23 -a 871 -i 127.0.0.1 Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time Slot, will i be able to listen what so ever broadcasting from HP8922 from C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Q.3) what command and interface will be used to enter the frequency hoping parameter, in case i will use FH option? to tune OsmocomBB l1CTL Q.4) How to enter Minimalistic L1 interface, what is interface available to insert theses command to layer1 DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND thanks , Martin

1 0

Presenting at event.
by Andrew Back 24 Sep '10

24 Sep '10

Hello, I'm involved with an open source hardware user group based in London: http://oshug.org Our next meeting is on Thursday 21st October and for which the theme is radio. We have one confirmed speaker who will be presenting on OpenHPSDR, and wondered if there might be someone around London at that time who might be willing to do a presentation on OsmocomBB and/or OpenBSC. For more info on OSHUG see the website for details of previous talks and photos and video. Regards, Andrew -- Andrew Back mailto:arback@gmail.com

1 0

Suggestions regarding the SIM code
by Harald Welte 23 Sep '10

23 Sep '10

Hi! I just found some time to have a look at the recent commit history and had a look at the SIM related code and had the following suggestions: 1) split the definitions from GSM TS 11.11 into a separate header file from the definitions that are OsmocomBB specific, and move the 11.11 header file into libosmocore 2) use msgb's for SIM messages. This way we can avoid all those manual buffer[N] = M type assignments and rather use msgb_put() constructs 3) even if not going for suggestion '2', it might be good to add some kind of a inline function abstracting out all the blocks that look like + buffer[0] = GSM1111_CLASS_GSM; + buffer[1] = GSM1111_INST_TERMINAL_PROFILE; + buffer[2] = 0x00; + buffer[3] = 0x00; + buffer[4] = length; with something like a "sim_buf_init(buffer, GSM11_INST_TERMINAL_PROFILE);" Of course those are simply suggestions... maybe for the day where somebody on this list is feeling bored and is looking for a quick and easy task to resolve. 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

job offer in berlin - breaking basebands, write open GSM tools
by Frank Rieger 20 Sep '10

20 Sep '10

I have a job offer in my company for a project to research into and build defenses against over-the air attacks breaking current 2G/3G basebands. The location is in Berlin, Germany, starting soon if possible. Remote work arrangements are not an option. The project is solidly financed by a public research grant, the company is nicely profitable for many years now. Requirements are detailed GSM knowledge, very good reverse engineering and at least decent C/C++ coding skills plus ability to work with a small team in english or german language. All research results of the project will be public and large parts of the development aspect will be on improving the open GSM / 3G tools and thus flow back to the community. Working hours are very relaxed, we are looking for someone who really dives into his work and does not just attend it. Mail me off list if you think you fit the profile. Thanks & Greetings from Berlin, Frank Rieger

1 0

AW: Some L1 updates
by Andreas.Eversberg 17 Sep '10

17 Sep '10

> * we should not try to introduce new 'hacks' but rather remove old > ones by proper code hi harald, if you sync the osmocore of osmocom-bb, i could remove some "#warning"s due to unavailable structures: struct gsm48_frq_redef struct gsm48_ho_cpl struct gsm48_ho_fail regards, andreas

2 2

Some L1 updates
by Sylvain Munaut 16 Sep '10

16 Sep '10

Hi, In my sylvain/testing branch, there a a few interesting changes: * Priority support for items in a scheduler bucket Basically for each sched_item, there is a now a priority field and they are executed in order. This allows for example to ensure that a scheduled freq change is executed before accesing the L1 parameters, or to make sure that a control channel RX is scheduled before a RACH TX ... For new items added into the bucket while executing itself (like the abort), those will obviously not be able to obey the priority and will always be executed afterwards. * Common DSP & TPU Scenario init & end Previously, each primitive _cmd initialized the TPU (with network/offset) to the timeslot and also ended the tpu & dsp scenario. This scheme doesn't work when you have several primitives that have a TPU window to open and/or a dsp scenario to run. (this happens when doing RACH in the same frame as reading a CCCH/BCCH bursts, or in the case of SDCCH8[4:7]). Now, each item specifies via some flags if he has a need for TPU and/or DSP. If one item of the bucket needs it, then the common code will handle. : - Aligning the TPU (via offset/network) to the 'base' timeslot (+3 TX offset still has to be added by the primitive) - Restoring base TPU alignement at the end. - Ending both TPU / DSP scenario when everything is done. * A5 support Andreas actually made L23 support and added a stub l1ctl_ command itself. Dieter and I actually made the L1 work in // and not surprisingly came up with very similar results given it's mainly: . Load the key in DSP API NDB & set the mode. . Set a fn parameter properly at each frame The rest is handled inside the dsp. I will now work on merging Dieter's work into the main branch above what I did. - TOA regulation loop to prevent drifting - TX power control - TCH support Cheers, Sylvain Munaut

2 1

interface for measurement reports
by Andreas.Eversberg 16 Sep '10

16 Sep '10

hi, i like to add layer1 control for measurement reports. my idea is use use normal L1CTL_DATA_REQ with SACCH channel type for sending the (updated) report to layer1. the protocol and message type will be decoded by layer1, so it can detect if this is a measurement report or not. if it is a measurement report, it will overwrite the last stored measuement report. it will be sent whenever there is no other SACCH message in the queue of SACCH messages. if it is not a measurement report, it will be queued as usual. any better idea? andreas

2 1

AW: Some L1 updates
by Andreas.Eversberg 16 Sep '10

16 Sep '10

really great work! i will check and play with it this weekend. looks like osmocom is getting to a state where it is "usable" very soon. andreas

1 0

Re: osmocom with USRP1 as a sw-only MS?
by Sylvain Munaut 14 Sep '10

14 Sep '10

Hi, > What's the easiest way to list out the API for layer1.bin? (I can start > searching through the code myself but I thought I would ask first.) See include/l1ctl_proto.h But it's a pretty high level: things like - Go camp on the bcch/ccch - Open a dedicated channel with those parameters - Send this L2 frame ... PS: Make sure to answer to the list and not me. Sylvain

1 0

AW: AW: assignment command / status of RR
by Andreas.Eversberg 08 Sep '10

08 Sep '10

> then i would suggest to expand the scheduling thing. i will see how > complex that would be... ok, i see that there is also a "one shot" scheduler with full frame number range. (sched_gsmtime.c) i think that i can use this to modify the current channel set. i have code to test it. i don't know if the callback function of the scheduled event is called before or after the actual transmission/reception of the burst, which also sets the right frequency. even if not, there will be only one frame lost.

2 1

AW: AW: assignment command / status of RR
by Andreas.Eversberg 07 Sep '10

07 Sep '10

> The only function in rfch.c returns the parameter for a given time. > It does _NOT_ and should _NOT_ make any change to the parameter itself. > That's left up to the caller because we need to call that function several time. > If you want to introduce some call that configure the channel and make changes and stuff, put it into another function and make sure it's called when required. then i would suggest to expand the scheduling thing. i will see how complex that would be...

1 0

AW: assignment command / status of RR
by Andreas.Eversberg 07 Sep '10

07 Sep '10

> Using the scheduler should be relatively easy, you can simply call > sched_gsmtime() and provide it a framenumber and a 'tdma_sched_item'. the > latter will contain the callback that is to be called once the current > framenumber will reach 'fn' as specified. what if there is already a scheduled item? in this case i must schedule the frequency change item before any other item. also the frame number of frequency change may be more than 255 frames ahead. my suggestion: because hopping sequence is a function of time, the starting time should also be included in this function (rfch.c).

2 1

osmocom with USRP1 as a sw-only MS?
by Fabio Pietrosanti (naif) 03 Sep '10

03 Sep '10

Hi all, after some days digging into the various tools around the GSM opensource playground arena i started understanding better the various piece of software. It seems to me that there's a net separation between the GSM implementation stack of OpenBTS and Osmocom, also because the projects are born with different goals. With the current bb implementation of Osmocom inside Calypso based baseband processor of motorola, all the DSP logic is done directly by the mobile phones chip, right? Which with OpenBTS, it's OpenBTS itself that does the modulation/demodulation along with the USRP. Is there some project and or ideas to bring together the DSP codebase of OpenBTS, together with OsmocomBB to make a MS terminal based on USRP1 device with RFX900 boards? Fabio

2 1

assignment command / status of RR
by Andreas.Eversberg 01 Sep '10

01 Sep '10

hi, as you can see in the git log, i checked in the "ASSIGNMENT COMMAND" processing. it modifies timeslot, subslot, and hopping sequence. this is required when the network assigns an SDCCH before the actual TCH is allocated: after receiving the "ASSIGNMENT COMMAND", the layer2 is release locally (without sending anything), the dedicated mode is released and established with a new parameters (e.g. TCH/F), and the layer2 is established again, finally the "ASSIGNMENT COMPLETE" is sent to the network. this process is incomplete, but it should work in most cases. (no "starting time" processing). in my local copy of the git, i already completed the assignment process. additionally "FREQUENCY REDEFINITION" is completed, "IMMEDIATE ASSIGNMENT" supports "starting time", MDL-error processing is added, and "HANDOVER COMMAND" parsing is done. the handover process is not completed, because it depends on unimplemented layer1 features, like RX-only channels or "4 successive HANDOVER ACCESS bursts on DCCH". except the handover process, the RR protocol for basic phone calls is complete now. before i can check it in, it depends on two things. first, there are additional messages to be defined in osmocore: "[osmocore] Adding handover and frequency redefiniton message headers" http://home.eversberg.eu/osmocore.patch second, it depends on "starting time" support for layer1: http://home.eversberg.eu/modify.patch it adds a L1CTL message to store modified frequency allocations (ma, ma_len, HSN, MAIO, TSC) for hopping and a "starting time". this starting time is the frame number at which the modified frequencies are used. if the frame number lies in the past, the new modified frequencies are used after the L1CTL message is received. sylvain already noted, that the event of "starting time" should be triggered by the scheduler. since i don't know how the scheduler exactly works, i would ask someone to change my patch. note that the dedicated mode can be released before the "starting time" elapses. as soon as both things above are in the master branch, i will commit my latest work on RR. regards, andreas

2 1

Hi all, why osmocombb need Ti Calypso/Iota/Rita GSM baseband chipset
by John Wu 01 Sep '10

01 Sep '10

Hi all, from what i learned, osmocombb provide gsm protocol stack and dsp signal process code. So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other common arm7+dsp chipset?

3 4

Re: SIM client
by Dieter Spaar 30 Aug '10

30 Aug '10

Hello Sebastien, On Mon, 30 Aug 2010 07:27:19 +0200, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote: > > For example, i don't remember what does a SIM says when it has to reply > data, but javacards reply 61XX and not something that starts with 9YXX. For GSM its 9Fxx (GSM11.11, 9.4. contains a list of all status codes). Not sure if this trace here is usefull (at the same site there is also one for an USIM): http://www.wrankl.de/UThings/SIM-ME-Communication.pdf Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: SIM client
by Dieter Spaar 30 Aug '10

30 Aug '10

Hello Andreas, On Sun, 29 Aug 2010 13:29:06 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > - add crpyto-key request to layer 1 and l1-l2 interface (dieter ?) I can take care of Encryption support in Layer-1. However I will probably not find time for it before next weekend. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

SIM client
by Andreas.Eversberg 29 Aug '10

29 Aug '10

hi, i committed the SIM client process for layer23. it turns reading and writing jobs (from and to SIM files) into APDUs. because the SIM reader is not yet finished, it cannot be tested yet. after attaching the SIM card, a process in mobile/subscriber.c will request all required files form that card before starting the network selection process. (untested, as noted above) the mobility management is now cleaned up: TODO comments in the source code are replaced by SIM update commands to the SIM client. in order to make mobile application work with public networks, we need to perform the following steps: - finish the SIM reader and interface in layer 1 - add BTSAP interface to layer23 - add measurement reports to both TCH and SDCCH4/8 (*) - send updates for measurement report from layer23 via l23 api of layer 1 - add crpyto-key request to layer 1 and l1-l2 interface (dieter ?) * tests showed that the measurement report on SDCCH4/8 is requred. if not sent, the network releases a call (cleanly) after the mobile stays for a some seconds on an SDCCH4/8 (probably waiting for measurements, before completing the call). sending some dummy measurements completed the call successfully. beside that, the following issues need to be solved soon, in order to make the layer 1 firmware usable and stable: - additional structures for the libosmocore, see http://home.eversberg.eu/osmocore.patch <http://home.eversberg.eu/osmocore.patch> - freeze of layer 1 after about 40-60 data messages, see http://home.eversberg.eu/data.patch <http://home.eversberg.eu/data.patch> for testing. after a few location updates firmware freezes. (the location update will fail, because the patch disturbs location updating process, but the bug show up.) - syncing problem - clock drifts away after sync - subchannels 4..8 of SDCCH/8 and maybe - tch mode l1ctl message to select signalling only / speech codec of TCH/F / TCH/H. (including bearer capability processing in layer23) regards, andreas

1 0

Wanted: Osmocom logo
by Harald Welte 24 Aug '10

24 Aug '10

Hi! It's about time that we find some kind of graphical project logo for the Osmocom project. Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN, OsmocomBB and others. So it might even be interesting to have some kind of 'family' of logos that all have the same general theme.... At least the bigger projects like OpenBSC and OsmocomBB definitely deserve their own incarnation within that family. If you want to contribute to our project but are not a die-hard C developer, this is your option to contribute! The logo must be under a license that permits use+modification for the Osmocom project itself. Editability for the general public is not important. With regard to formats, I would prefer something as SVG that we can then render into pngs of various sizes whenever there is demand for it. If you have a proposal, simply send it (or a link to a URL) to the openbsc(a)lists.gnumonks.org mailing list. Thanks in advance for any submissions! -- - 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 5

using BTSAP from layer23
by Andreas.Eversberg 23 Aug '10

23 Aug '10

hi, i am current writing the sim client for layer23. this client transforms the read and update requests from layer 3 (imsi read, location update) into several APDUs to be transferred via BTSAP interface. (interface to layer 1) here are two questions: how do i interface to this BTSAP? i see that there is another unix socket for that. do i need to expand main.c of layer23? i think that i cannot just start sending APDUs after starting layer23. there might be something like an initialization sequence before: - power on - reset - get atr - ... - send APDU - receive APDU - ... is there a defined sequence or flow chart for that? regards, andreas

2 1

AW: sim client
by Andreas.Eversberg 19 Aug '10

19 Aug '10

hi sebastien, thanx for you advice. i will have job names like SIM_JOB_READ, SIM_JOB_UPDATE, SIM_JOB_GSMALGO,... i am a bit unsure about the path array. i always thought that each EF has a unique ID. the DF where it is located, can be determined by the first byte of the EF ID. but if it is possible to have a sim with multiple DFgsm, then a path is required of course. for PIN handling, i will use result codes that gives cause of an error. if a PIN is required (to read the IMSI for example), the error code would show that. then the sim reading process prompts for PIN. the SIM can be unlocked ("enabled") by a message like SIM_JOB_ENABLE_CHV1. outgoing data (UPDATE) is located behind the header. incomming data is also located behind the header when the job returns (callback fn is called). but the READ job must be triggered. when my code must deal with record types, i will expand the header. i will create the API step by step. regards andreas

3 3

sim client
by Andreas.Eversberg 17 Aug '10

17 Aug '10

hi, i like to write the sim client protocol. i do not mean the code of the "sim reader" which is part of layer1 inside the phone. before i start, i would like to know what you think about my api idea. the api is not the low-level api between layer1 and the mobile application (APDU layer). it describes a higher layer for application or protocol processes which need to request IMSI, do key generation, or store location area information. one important thing is that different processes must be able request "read", "write", or other operations like key generation simultaniously. in order to handle multiple requests after each other, a queue inside sim client must exist. afterwar processing each request, the result must be sent only to the requesting process (if it still exists). a state machine watches over the current DF (current selected file area of the sim) and changes current "DF" if required, before processing read or write job. also it triggers the next job in the queue, if finished with the current one. int handle = sim_open(void (*cb)(...)) will add a new user instance. cb is the function to be called for response, handle is a unique id of the process (not a memory pointer, unique at all times after starting phone). void sim_job(struct msgb *msg) struct sim_job_hdr { int handle; uint8_t job_type; uint16_t file; }; will add a new job. the type defines the job type. examples are "READ" "WRITE" or "GSMKEY" requests. the handle is used to assign the read/write job to an instance. the file is used to select the correct data file of the sim. the data and len represent the data to be written. void cb(struct msgb *msg) is called back by the sim client when job is done. the handle is given, so multiple user instances may use the same callback. void sim_close(int handle) will remove user instance. outstanding jobs will finish, but no result is given, because cb is now unregistered. the coding and decoding of SIM files must be done by the application or protocol layer that use the sim client. andreas

2 1

layer1: crash after receiving TX data
by Andreas.Eversberg 16 Aug '10

16 Aug '10

hi, me and maybe some of you experiences sudden freeze of the layer1 firmware. it happens sometimes when sending L1CTL_DATA_REQ from layer2 to layer1. i found a way to reproduce it. see http://home.eversberg.eu/data.patch for testing it. just apply this patch and uncomment the "´#define" line. this patch will transmit idle frames, if there is no frame in the tx-queue of lapdm. (DCCH) even if there is a frame to be sent, the lapdm process will wait until the data is confirmed by layer1 until sendig the next frame. this confirm is sent when the data has been transmitted by layer1 (i think). this is why the queue inside layer1 cannot overflow. this patch does not work correctly somehow. when sending the idle frame, the location update seems not to work. the lapdm fails. but this doesn't matter for the crash-test. until then, more than 20 frames are transmitted. if the mobile application is restarted, more frames will be transmitted. between 45 and 60 frames later the layer1 freezes. the display gets a little darker also. andreas

1 0

Status of Traffic channel
by Dieter Spaar 13 Aug '10

13 Aug '10

Hello, here is some information about the current status of traffic channel support in Layer-1: - first of all its not yet complete and considered "alpha" because there are some stability problems which have to be solved and some further enhancments for a more general approach are needed. - What works: Signalling (FACCH/SACCH) for a Full Rate Traffic channel and voice (Full Rate or Enhanced Full Rate Codec). - TODO: The Layer-1 API has to be extended to allow switching the channel mode (e.g. Signalling only) or the Voice Codec. Also turning the audio path on and off is needed. - TODO: The Rx/Tx TPU Window has been modified to support Rx and Tx operation in the same frame. This always happens for a Traffic Channel but can sometimes also happen for other channels. For those cases its necessary that the Tx TPU Window is set differently. Some sort of state information that Rx is happening in the same frame has to be implemented, this currently only works for traffic channels. If you want to try it out you have to use the "dieter/tch_f" branch for Layer-1 and the Master branch for Layer-23 from Andreas (really great work, Andreas). With this combination you can use it with OpenBSC. Some minor adjustment is needed: The Layer-1 code currently sets the voice Codec to "Full Rate", however OpenBSC expects "Enhanced Full Rate" You either have to modify OpenBSC to set "Full Rate" or change "TCH_FS_MODE" to "TCH_EFR_MODE" in "layer1/prim_rx_nb.c", there is only one line which has to be changed. What you can do now is a MOC/MTC between OsmocomBB and another phone. Sometimes it can happen that the firmware hangs, you have to restart the phone in this case. However if you have a connected call, its working pretty good (one of the test calls was over 20 minutes). Maybe Andreas can give a short introduction how to use Layer-23 for this, I am not sure if there is some information in the Wiki yet. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Who would attend a developer room / meeting at FrOSCon ?
by Harald Welte 04 Aug '10

04 Aug '10

Hi! I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/) which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin from August 21/22 this year. Before sending a response, I would like to inquire whom of you would actually have any intention of visiting this conference and spending time in the developer room to work on OpenBSC or OsmocomBB ? I think the idea is great to meet some of you guys [again], not only at the annual CCC congress in winter. But there is little point for me to go there if there is no interest from the wider project community. Please provide your feedback ASAP. -- - 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)

3 4

Re: Wanted: Osmocom logo
by Steve Markgraf 03 Aug '10

03 Aug '10

Hi, On 02.08.2010 14:36, Sylvain Munaut wrote: > A nice typo with just 'osmocom' and a free space to put the suffix > ('bb' 'sgsn' ...) either in another typo or just using the bold face > and then just some _discrete_ graphical element added to the typo ... > > But IMHO certainly not some complex graphical only element. Ack, that's what I'd suggest as well, something clean and simple. So here's my RFC: I've taken the wireless symbol Kevin posted, and added a lettering. The font used is "Yanone Kaffeesatz" [1], which is licensed under the Open Font License. I attached osmocom_inkscape.svg, for which you need to have the font installed, and can then play around and edit the text, and a "object-to-path" converted osmocom_paths.svg, which is just a plain vector graphic. If anyone has an idea how to decently make the difference between osmocomBB and BSC more clear, or even has a completely different idea, let us hear/see them :) Regards, Steve [1] http://www.yanone.de/typedesign/kaffeesatz/

13 19

Re: OsmocomBB, Problem , prospects discussed
by Dev Purohit 02 Aug '10

02 Aug '10

Hello Peter, >Please reconsider this position. "once finished" is way too late to be useful, unless you plan on creating a product that you will sell. If you want cooperation and feedback from the community then I rather strongly suggest sharing source code immediately when you start the >work. Thanks you for your concerns, But as i have clearly mentioned that i have implemented Frequency Hoping, on DATA communication device ( telemetry on ISM Band) and Hardware Platform ,communication schemes , protocols and modulation technique were very different, so source can't be integrated with OsmocomBB at this stage , even patching also not that easy i estimated, and most difficult thing is i have very limited knowledge of G.S.M , my mostly time is consuming to study specifications .. Ohh, very lengthy subject.. anyways , I'm trying to deploy for cyclic FH first , choosing right algorithm. i have no problem or commercial value for sharing my work with great people , but it at least relevant and use full to this project. I'm neither developing any equipment not planning to sell it.. MatLab is simulation platform and codes cant be implemented in real-time or live environment, also it support TI DSP's long range. so we can debug change to C header after wards. Kind regards, Dev --- On Sun, 8/1/10, baseband-devel-request(a)lists.osmocom.org <baseband-devel-request(a)lists.osmocom.org> wrote: From: baseband-devel-request(a)lists.osmocom.org <baseband-devel-request(a)lists.osmocom.org> Subject: baseband-devel Digest, Vol 7, Issue 1 To: baseband-devel(a)lists.osmocom.org Date: Sunday, August 1, 2010, 10:00 AM Send baseband-devel mailing list submissions to baseband-devel(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/baseband-devel or, via email, send a message with subject or body 'help' to baseband-devel-request(a)lists.osmocom.org You can reach the person managing the list at baseband-devel-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of baseband-devel digest..." Today's Topics: 1. OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Dev Purohit) 2. Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Dieter Spaar) 3. Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Peter Stuge) _______________________________________________ baseband-devel mailing list baseband-devel(a)lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/baseband-devel

1 0

sorry, my e-mail got hacked...
by Lubomir Schmidt 02 Aug '10

02 Aug '10

sorry for the spam mails. My e-mail got hacked...

1 0

[ANNOUNCE] planet.osmocom.org
by Harald Welte 01 Aug '10

01 Aug '10

Hi! We now have a planet (RSS feed aggregator) for the Osmcoom project, it's running at http://planet.osmocom.org/ Please let me know if you think I should add any feeds to it. There is no strict requirement for contributions to the Osmocom project, but it should be technical and related to protocols / hacking / development of mobile telephony systems. 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

OsmocomBB, Problem , prospects discussed.. with Mr. Spaar..
by Dev Purohit 01 Aug '10

01 Aug '10

>Do you already have experience with Osmocom and tried it >with a phone ? No i haven't , tried Osmocom with a phone yet, i have C139 and C117 available, once i tried but it reach up to downloading finish (of binary in firmware folder). after that it keeps in that state for quite some time and shows download NACK after wards, something went wrong , then operation aborted. i tried many times with it. As i don't have much experience with HDLC or serial communication to UART, some binary files even do not download completely and receive FMTOOL abort.. while downloading I'm using prolific USB serial DATA cable ( seems very noisy) but no choice as my notebook doesn't have a serial port :-( I'm thinking to assemble new PC though. I need you kind suggestions in this regard. >What exactly do you want to do ? Only receive voice traffic ? >You want to switch to an ARFCN and timelslot and listen to >the voice traffic ? Of course this only works if the channel >is not encrypted or you have Kc for decryption. Yet again if i'm able to run the code and even able to interact using L2/3 or osmoload with phone i don't know how to use phones analogue BaseBand ( ADC) and download the fetched raw data after ( (of desired ARFCN n TS) to host PC and save it in *.cfile format or MatLab( simulink) supported format , if i'm able to do up to this extent i'm pretty sure i can convert it into Voice as i'm reasonably sound with MatLab... Of course , the TCH/F should be without encryption, but i will create a interface in MatLab codes to supply Kc , if available, for future use. ( for digital BB processing ) >What about frequency hopping ? Without knowing the hopping > sequence its not possible to follow a hopping channel. Though i'm not die -hard with C or C++ , but rather fine. have previous understanding for implementing frequency hopping in ISM band, have seen protocol analysis using wireshark we can can easily extract hopping sequence and and chase it , big problem is not to tune PLL synthesizer, but Time slot. and collecting the buffered data for processing , for this i have clear vision, i will share my source codes with you once finish my work.

2 1

Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar..
by Dieter Spaar 31 Jul '10

31 Jul '10

Hello Dev, On Sat, 31 Jul 2010 04:21:57 -0700 (PDT), "Dev Purohit" <devpurohit19(a)yahoo.com> wrote: > Yet again if i'm able to run the code and even able to interact using > L2/3 or osmoload with phone i don't know how to use phones analogue > BaseBand ( ADC) and download the fetched raw data after ((of desired ARFCN > n TS) to host PC and save it in *.cfile format or MatLab( simulink) > supported format , if i'm able to do up to this extent i'm pretty sure i > can convert it into Voice as i'm reasonably sound with MatLab... The DSP does not directly deliver the raw ADC samples. You can get them with some tricks but this won't help much because the UART is not fast enough to transfer them continuously to the PC. As far as I know Sylvain is trying to get the demodulated raw data bits out of the DSP, he can tell you better about his progress. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Some refactoring proposals
by Sylvain Munaut 29 Jul '10

29 Jul '10

Here's a few refactoring proposal that I'd like to get done. But before I invest too much time in them I'd like to be sure there are no objections ... (I hate implementing stuff for nothing). * Split layer23/src into - common: what makes liblayer23, purely generic stuff that needs binding together to define an app - mobile: The real complete mobile application - misc: The test applications and their support code layer23 (which I'd rename bcch_dump since that's what it does), echo_test, bcch_scan) * Move away from dispatching L1CTL message using signals ... Only L1CTL works like that and I just can't figure out why ... we read the l1ctl messages just to move their data into another structure to redispatch them to a handler ... l1ctl.c should just contain: - The l1ctl_tx_XXX primitives - A function for the 'application' to register it's own handler for L1CTL messages. - The rx call back to be called by lower layer when a l1ctl frame is received. This one would get the frame, set the hdr pointers, do basic checks, possibly allow signal dipatching for the RESET signal (which is kinda special), and then just hand the frame to the registered handler. * Split lapdm.c : Currently it contains lapdm code and RSLms. They should be split and lapdm code should not be tied to a specific usage but be 'instantiated'/configured in each app as they see fit. Some app might need to track more than 2 lapdm channels ... - lapdm.c would be in common/ (more like an utility lapdm library than 'business' code) - rslms.c would probably be in mobile/ * Rework the app in misc/ to remove the over-engineered bits. It's clear from the sources that layer23 intended to become the full featured phone and as such, is split in a bunch of elements for ... not much in the end since Jolly restarted from scratch, splitting better. So I'd like to simplify as much as possible those apps while still separating 'utilities' function (like dump_bcch) to allow re-use between them. Theses are only the first few steps. My goal is to make it more easy to write small test applications and to clearly separate that from the full featured / layered mobile implementation while still sharing the relevant 'library type' code. Cheers, Sylvain

3 6

AW: Some refactoring proposals
by Andreas.Eversberg 28 Jul '10

28 Jul '10

surely i agree! (as i noted in my last mail) -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Mittwoch, 28. Juli 2010 09:17 An: Sylvain Munaut Cc: baseband-devel; Andreas.Eversberg Betreff: Re: Some refactoring proposals On Tue, Jul 27, 2010 at 09:02:02PM +0200, Sylvain Munaut wrote: > Hi, > > >> * Split layer23/src into > >> - common: what makes liblayer23, purely generic stuff that needs > >> binding together to define an app > >> - mobile: The real complete mobile application > >> - misc: The test applications and their support code layer23 (which > >> I'd rename bcch_dump since that's what it does), echo_test, bcch_scan) > > > > Sounds fine with me. If Andreas doesn't mind, I'm happy to merge a branch > > containing this split > > Ok, this is done. It's waiting in my pending branch with a bunch of > other fixes. It requires a libosmocore update as well. I'll wait for some feedback from Andreas. If he either agrees or doesn't care, then I'll merge it. > (I moved a func to libosmocore, which required to update it, which > bringed the msgb checks, which broke the target build and required > fixing, it also showed some bugs in fw and layer23 code that required > fixing as well ...) I've merged your pending libosmocore changes to libosmocore.git master. -- - 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

AW: Some refactoring proposals
by Andreas.Eversberg 28 Jul '10

28 Jul '10

>> Here's a few refactoring proposal that I'd like to get done. But >> before I invest too much time in them I'd like to be sure there are no >> objections ... (I hate implementing stuff for nothing). >> >> * Split layer23/src into >> - common: what makes liblayer23, purely generic stuff that needs >> binding together to define an app >> - mobile: The real complete mobile application >> - misc: The test applications and their support code layer23 (which >> I'd rename bcch_dump since that's what it does), echo_test, bcch_scan) > > Sounds fine with me. If Andreas doesn't mind, I'm happy to merge a branch > containing this split i don't mind!

1 0

Progress..
by Dev Purohit 25 Jul '10

25 Jul '10

Hi All, I just want to elaborate it my question is is there is some down link traffic between MS and a testing BTS , let say on ARFCN # 13 and Time slot 3 this traffic channel is non encrypted A5/0 , is osmocom BB or airprob is become to capable to tune to that particular ARFC in this case ARFCN no. 13 and time slot 3 and fetch the traffic channel data process it and convert it to pure voice or encode speech signals ( (CELP) or PCM format ) i specifically request to Harald as he is taking care for airprob also. If these projects need more development to get this extent kindly guide me so that i can start my work and contribute to this project , why taken I have taken this approach is 1) will clarify other aspects and errors in this package to make a working, ready to use package. after wards we will start for transition section. 2) will confirm the feasibility and give all contributor a enthusiasm that we are developing significantly and can get at least any output from moths of hard work 3) will apply the changes and correct for the errors( instability) other developer and contributor will face or report during their voice reception. i feel reception of voice , then transition of voice is very basic requirement of any mobile software, then we can add on other features like channel hoping , cell handovers, other UI features , various multimedia and messaging features.. thanks for your great work and wish to contribute at my best abilities.. --- On Fri, 7/23/10, Dev Purohit <devpurohit19(a)yahoo.com> wrote: From: Dev Purohit <devpurohit19(a)yahoo.com> Subject: progress.. To: baseband-devel(a)lists.osmocom.org Date: Friday, July 23, 2010, 12:49 PM Hello All, My basic question is related to progress and accomplishment of this project and related project like airprob. 1 if any of these project have reached up to the point where Um or Abis interface traffic can be change to voice or at least to the stage where it can get PCM or ISDN level voice data let say through layer1application we change synthesizer frequency to specific ARFCN, and tune to a specific TS. can it fetch traffic( without encryption, a5/0, testing down link traffic between MS and testing BTS ) channel and after base-band processing can it give voice data (either PCM o, analogue format, digital voice coding) if so what all sections/ applications will involve of this application or if this is possible through airprob so for now. Thank you in advance..

2 1

progress..
by Dev Purohit 23 Jul '10

23 Jul '10

Hello All, My basic question is related to progress and accomplishment of this project and related project like airprob. 1 if any of these project have reached up to the point where Um or Abis interface traffic can be change to voice or at least to the stage where it can get PCM or ISDN level voice data let say through layer1application we change synthesizer frequency to specific ARFCN, and tune to a specific TS. can it fetch traffic( without encryption, a5/0, testing down link traffic between MS and testing BTS ) channel and after base-band processing can it give voice data (either PCM o, analogue format, digital voice coding) if so what all sections/ applications will involve of this application or if this is possible through airprob so for now. Thank you in advance..

1 0

socket running problem
by Dev Purohit 18 Jul '10

18 Jul '10

Hello Mr.Holger, Thank you so much for help, but i'm not expert with linux system yet kindly help me to interpret. where is problem ? thank you in advance xx@ubuntu:~/osmocom-bb/src/host/osmocon$ strace -Ff -tt osmoload 2>&1 | tee strace-osmoload.log04:36:51.842667 execve("/usr/local/sbin/osmoload", ["osmoload"], [/* 38 vars */]) = 0 04:36:51.877698 brk(0) = 0x9b95000 04:36:51.877918 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 04:36:51.878154 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78f9000 04:36:51.878338 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 04:36:51.878657 open("/etc/ld.so.cache", O_RDONLY) = 3 04:36:51.878810 fstat64(3, {st_mode=S_IFREG|0644, st_size=82613, ...}) = 0 04:36:51.879022 mmap2(NULL, 82613, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb78e4000 04:36:51.879105 close(3) = 0 04:36:51.879221 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 04:36:51.879384 open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 04:36:51.879554 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000m\1\0004\0\0\0"..., 512) = 512 04:36:51.879724 fstat64(3, {st_mode=S_IFREG|0755, st_size=1405508, ...}) = 0 04:36:51.879956 mmap2(NULL, 1415592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xe50000 04:36:51.880093 mprotect(0xfa3000, 4096, PROT_NONE) = 0 04:36:51.880219 mmap2(0xfa4000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153) = 0xfa4000 04:36:51.880373 mmap2(0xfa7000, 10664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xfa7000 04:36:51.880540 close(3) = 0 04:36:51.880681 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78e3000 04:36:51.880837 set_thread_area({entry_number:-1 -> 6, base_addr:0xb78e38d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 04:36:51.881137 mprotect(0xfa4000, 8192, PROT_READ) = 0 04:36:51.881301 mprotect(0x8050000, 4096, PROT_READ) = 0 04:36:51.881443 mprotect(0x319000, 4096, PROT_READ) = 0 04:36:51.881572 munmap(0xb78e4000, 82613) = 0 04:36:51.881845 socket(PF_FILE, SOCK_STREAM, 0) = 3 04:36:51.882040 connect(3, {sa_family=AF_FILE, path="/tmp/osmocom_loader"}, 21) = -1 ENOENT (No such file or directory) 04:36:51.882323 write(2, "Failed to connect to '/tmp/osmoc"..., 44Failed to connect to '/tmp/osmocom_loader'. ) = 44 04:36:51.882700 exit_group(1) = ? xx@ubuntu:~/osmocom-bb/src/host/osmocon$

3 2

socket running problem
by Dev Purohit 17 Jul '10

17 Jul '10

Hi all i run command osmocom-bb/src/host/osmocon# ./osmoload Failed to connect to '/tmp/osmocom_loader' and osmocom-bb/src/host/layer23/src# ./layer23 Failed to connect to '/tmp/osmocom_l2'. Failed during layer2_open() kindly help me out with this i'm stuck.. Dev.

2 1

kernel choice
by Scott Weisman 14 Jul '10

14 Jul '10

Hi all. I just swallowed the Osmocom red pill and am awaiting my Motorola V171 which I just bought on eBay (it was the cheapest option). I was interested in what people thought of the Contiki OS. I'm not an expert, but this seems like a good option, since it's very compact, and has been ported to many ARM-based devices. Scott

2 1

AW: OsmocomBB Layer1 progress
by Andreas.Eversberg 05 Jul '10

05 Jul '10

> JFYI: The AGC control in L1 is now active. At least it didn't make things > worse for me. Maybe people who have had problems acquiring weak cells > should give it a try again. > I suggest to add the L1CTL_DM_REL_REQ into the state machine, I suppose > it should avoid that problem. hi, i will check this issue about releasing and establishment of dedicated mode. also i will do the power control thing from L3. i got stuck while transcoding RACH request / confirm from L1CTL into RSL_CHAN_RQD/RSL_CHAN_CONF. the goal is to have pure RSL between layer 3 and layer 2. the biggest problem are things like power measurement, sync requests and other L1CTL messages, all which are not defined for RSL SAP. i don't like the idea about converting everything from L1CTL to RSL and parsing it and vice versa. this take allot of time to implement, also we would need to add several new messages and information elements. my suggestion is to leave L1CTL as it is. currently i think about how to control tx_power and TA (timing advance/delay) from layer 3. it is not possible to set them in every layer 3 message, because this message may be splitted or repeated or layer 2 may send responses without interaction of layer 3. therefore we must store the tx_power and TA at layer 2, and it must be sent with every frame then. since we don't send any idle frame to layer 1 (this is actually generated there), we can only give tx_power and TA at frames with content. the values must be stored at L1 for idle frames. therefore it think it would be much easier to use something like L1CTL_POWER_REQ to set the current tx_power and a L1CTL_POWER_CONF to get the actual (closest) power set. (also includes the TA). these values are stored and for every frame sent afterwards until L1CTL_POWER_REQ is sent with different values. regards, andreas

1 0

Running osmocombb on a Motorol C118
by Maciej Grela 02 Jul '10

02 Jul '10

Hi, I've recently bought two Motorolas C118 with the intent of trying osmocombb. I have trouble running the firmware correctly however. Here are the steps I'm taking: 1. Run osmocom: thermal@richese:~/Publiczny/devel/osmocombb/osmocom-bb/src/host/osmocon$ ./osmocon -p /dev/ttyUSB0 -m c123 /home/thermal/Publiczny/devel/osmocombb/osmocom-bb/src/target/firmware/board/compal_e88/layer1.ramload.bin 2. Press power on the phone. 3. Phone boots and downloads code from osmocon (this code lands in RAM I presume) Received PROMPT1 from phone, responding with CMD read_file(/home/thermal/Publiczny/devel/osmocombb/osmocom-bb/src/target/firmware/board/compal_e88/layer1.ramload.bin): file_size=40232, hdr_len=4, dnload_len=40239 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 1087 bytes (1087/40239) handle_write(): 768 bytes (1855/40239) handle_write(): 768 bytes (2623/40239) handle_write(): 768 bytes (3391/40239) handle_write(): 768 bytes (4159/40239) handle_write(): 768 bytes (4927/40239) handle_write(): 768 bytes (5695/40239) handle_write(): 768 bytes (6463/40239) handle_write(): 768 bytes (7231/40239) handle_write(): 768 bytes (7999/40239) handle_write(): 768 bytes (8767/40239) handle_write(): 768 bytes (9535/40239) handle_write(): 768 bytes (10303/40239) handle_write(): 768 bytes (11071/40239) handle_write(): 768 bytes (11839/40239) handle_write(): 768 bytes (12607/40239) handle_write(): 768 bytes (13375/40239) handle_write(): 768 bytes (14143/40239) handle_write(): 768 bytes (14911/40239) handle_write(): 768 bytes (15679/40239) handle_write(): 768 bytes (16447/40239) handle_write(): 768 bytes (17215/40239) handle_write(): 768 bytes (17983/40239) handle_write(): 768 bytes (18751/40239) handle_write(): 768 bytes (19519/40239) handle_write(): 768 bytes (20287/40239) handle_write(): 768 bytes (21055/40239) handle_write(): 768 bytes (21823/40239) handle_write(): 768 bytes (22591/40239) handle_write(): 768 bytes (23359/40239) handle_write(): 768 bytes (24127/40239) handle_write(): 768 bytes (24895/40239) handle_write(): 768 bytes (25663/40239) handle_write(): 768 bytes (26431/40239) handle_write(): 768 bytes (27199/40239) handle_write(): 768 bytes (27967/40239) handle_write(): 768 bytes (28735/40239) handle_write(): 768 bytes (29503/40239) handle_write(): 768 bytes (30271/40239) handle_write(): 768 bytes (31039/40239) handle_write(): 768 bytes (31807/40239) handle_write(): 768 bytes (32575/40239) handle_write(): 768 bytes (33343/40239) handle_write(): 768 bytes (34111/40239) handle_write(): 768 bytes (34879/40239) handle_write(): 768 bytes (35647/40239) handle_write(): 768 bytes (36415/40239) handle_write(): 768 bytes (37183/40239) handle_write(): 768 bytes (37951/40239) handle_write(): 768 bytes (38719/40239) handle_write(): 768 bytes (39487/40239) handle_write(): 752 bytes (40239/40239) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 42 B Received DOWNLOAD ACK from phone, your code is running now! Hello World from apps/layer1/main.c program code ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: 058d320a9e039bfc ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ====================================================================== THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!! Assert DSP into Reset Releasing DSP from Reset Setting some dsp_api.ndb values Setting API NDB parameters DSP Downlad Status disabledDSP API Version: 0x0000 0x0000 Finishing download phase DSP Downlad Status disabledDSP API Version: 0x3606 0x0000 What is the layer1 firmware supposed to do now ? I've tried to run layer23/bcch_scan and layer23/layer23 but they don't print any messages and so does the firmware itself. I'm under the impression that the firmware freezes. Have you tested the firmware on a C118 phone ? I will try to find out why it's freezing but maybe I'm missing something obvious ? Best regards, Maciej Grela

2 2

Project hardware question
by Drasko DRASKOVIC 01 Jul '10

01 Jul '10

Hi, I have been looking for sometime at OsmocomBB project, but haven't tied it yet. I have seen that software supports a number of Compal phones : Supported Phone hardware Information specific to certain Calypso based phones that we support Designed + Manufactured by Compal, OEM by Motorola MotorolaC115/C117 (E87) MotorolaC123/C121/C118 (E88) -- our primary target MotorolaC140/C139 (E86) MotorolaC155 (E99) -- our secondary target MotorolaV171 (E68/E69) SonyEricssonJ100i So, I was wondering: 1) Which would be best to have to start with, as the most supported target ? 2) Where I can get this phone quickly and easily ? 3) What additional equipment is needed (how do you flash the software and how do you debug) ? 4) Is there some software simulator in which I could see what is happening and how the SW works without actual HW equipment ? Best regards, Drasko

2 1

RSL of Osmocom
by Andreas.Eversberg 30 Jun '10

30 Jun '10

hi, i like to do extensions to the RSLms layer of osmocom. before that i like to ask and discuss if this would be the correct way: instead directly of calling l1ctl_* functions of l1ctl.c, i would like to use RSL messages between layer 2 and layer 3. the lapdm.c would then convert these messages and call l1ctl_* functions. (maybe i could split up lapdm.c into lapdm.c and layer2.c. the selecting the handler for an RSL request could be made at layer2.c, as well as selecting the right handler for the frames received from layer1. only the lapdm part could be handled in lapdm.c. ) the RACH request could be sent using RSL_MT_CHAN_RQD, the confirm could be the same message type, but i prefer to invent a new one: 0x18, but using the same IE layout. also including RSL_IE_MS_POWER_PARAM with the RACH request, could tell the layer 1 about usage of power and TA (which is normally 0 for RACH request). the (UNIT) DATA request may also include RSL_IE_MS_POWER_PARAMS. if omitted, the stored value from the last message with RSL_IE_MS_POWER_PARAMS could used. the (UNIT) DATA indication and request of SACCH may include RSL_IE_L1_INFO IE to receive power and timing control as well as send the actual power and timing advance. i could handle these IE at layer 3 (radio ressource) and forward them to layer 1 (RSL_IE_MS_POWER_PARAM) depending on the supported radio power and on special VTY settings to mess with power and fake timing advance. regards, andreas

2 1

Constructors
by Harald Welte 29 Jun '10

29 Jun '10

Hi! As indicated in other mails, we now have support for gcc-style constructors in OsmocomBB. The way to use them is relatively easy: Simply put "__attribute__((constructor))" at the function that you want to be called during initialization. The way how this works is like this: * gcc and the linker create a table of function pointers to all the functions with that attribute * the code in compal_ramload_start.S takes care of calling lib/ctors.s:do_global_ctors() which iterates over the list and calls each constructor This concept is now used for things like prim_fbsb_init() in layer1, but I have also started to use it for board_init(). This means that board_init() no longer needs to be called from the main() function of each app. We can probably put more stuff into constructors, but we should also be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus there is no explicit way to control the ordering in case of dependencies. 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)

3 3

OsmocomBB Layer1 progress
by Harald Welte 26 Jun '10

26 Jun '10

Hi all! JFYI: The AGC control in L1 is now active. At least it didn't make things worse for me. Maybe people who have had problems acquiring weak cells should give it a try again. I've also fixed some compile problems due to a missing header file, and there is now a L1CTL_DM_REL_REQ where Layer23 can explicitly release the dedicated mode and return to idle mode. Right now the 'mobile' program (specifically gsm322/gsm48_rr) issue another L1CTL_PM_REQ after a location update reject hap[pens, i.e. layer1 is still in dedicated mode but it gets some power measurements. This results in L1 trying to do Transmit in parallel with power measurements and it crashes at some point. I suggest to add the L1CTL_DM_REL_REQ into the state machine, I suppose it should avoid that problem. 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

Some L1 status updates
by Sylvain Munaut 24 Jun '10

24 Jun '10

Hi, The good news, is that hopping and ts[0:4] work just fine and were surprisingly easy to implement. The bugs I thought I had were in fact not related to these and just prior bugs that were never noticed before. (see my sylvain/testing branch). Only L1 is changed, so you'll need to tweak l23 (either the mobile app or layer23 for quick tests) if you want to try them out somehow. Current limitations: - SDCCH8 subchannel 4,5,6,7 won't work. For those, we need to TX and RX in the same frame ... which just isn't possible with the way the primitives work right now. (each assume to have the full frame for themselve). - TS >= 4 may not work When using TS>=4 we should also change the interrupt alignment so that the DSP still has time to do it's job. Switching 'forward' is easy, but when switching 'back', we need to be conscious that we need to skip 1 frame at the very least ... IMHO to solve both those issue, we need a better scheduler/primitives that possibly have some knowledge of the 'span' (in terms of qbit) of each operation. Because if we do a TX on TS=5 for instance, there is no way we can do a RX on TS=0 on the next frame, the tpu window overlap. - No ciphering. That should be trivial to add. Just setup the fn and the kc and set the flag ... the 'l1s.next_time' contains the godd time of the frame TX/RX frame during the primitive execution, so that's the FN to use. Once that's done, the few bits missing from mobile app could be added (and from a quick look, not much is missing ... just the l1ctl_* calls because they don't exists yet) and a full location update with auth and ciphering could be done. The need for a SIM interface grows quickly :) Some 'gotchas' you might encounter that are not fixed yet: - The L1 completion handler crashes. In target/firmware/layer1/prim_tx_nb.c , l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's never called. So you need to comment out l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until a proper fix. - Wireshark SDCCH8 subchannel decoding in IMMEDIATE ASSIGNEMENT is just plain wrong. (source code uses % 0x38 instead of & 0x38), need to send a patch for this - layer23 doesn't currently filter much the IMM.ASS it receives so you may end up on a channel that's not yours ... beware. Sylvain

2 3

AW: Some L1 status updates
by Andreas.Eversberg 24 Jun '10

24 Jun '10

> - layer23 doesn't currently filter much the IMM.ASS it receives so > you may end up on a channel that's not yours ... beware. hi sylvain, what do you mean with "much"? i filter the channel with the channel request number (includes random number) in the IMM.ASS message. maybe in the future we can filter the time slot where it was sent (RACH confirm) and compare it also. but this requires RACH confirm with GSM time where it was sent. andreas @harald: is there any time stamp in the RACH confirm? what format would it be? .... from the IMM.ASS parsing: /* 3.3.1.1.2: ignore assignment while idle */ if (rr->state != GSM48_RR_ST_CONN_PEND || !rr->wait_assign) { LOGP(DRR, LOGL_INFO, "Not for us, no request.\n"); return 0; } /* request ref */ if (gsm48_match_ra(ms, &ia->req_ref)) { /* channel description */ memcpy(&rr->cd_now, &cd, sizeof(rr->cd_now)); /* timing advance */ rr->cd_now.ta = ia->timing_advance; /* mobile allocation */ memcpy(&rr->cd_now.mob_alloc_lv, &ia->mob_alloc_len, ia->mob_alloc_len + 1); rr->wait_assign = 0; return gsm48_rr_dl_est(ms); } LOGP(DRR, LOGL_INFO, "Request, but not for us.\n");

3 2

AW: Some L1 status updates
by Andreas.Eversberg 23 Jun '10

23 Jun '10

> I was refering to "layer23" the quick & dirty test app if you want to > play with the layer1. oops. sorry, but anyway i need to improve the IMM.ASS. check against timestamp. i will test all the new features soon and also check the time stamps if they match.

1 0

l1test without hdlc (sercomm)
by Rust, Marco 22 Jun '10

22 Jun '10

Hello, I want to use the power measurements from the l1test in the phone. Therefore I modified the program so only the PM is done and additional some averaging and so on. Finally the information should be sent to an microcontroller over UART. There is the problem: I don't know how to use this HDLC sercomm stuff because I don't have time to understand AND implement it for my thesis in the µc-part. I need a quick dirty hack to deactivate this HDLC. I don't find it in code and tried some hours. I tried "uart_putchar_wait()" and hterm shows me that the bytes are sent with a lot other stuff. What is the easiest way working for me? Thanks a lot. Marco

2 2

[PATCH] l1ctl.c: add missing ntohs for band_arfcn
by Jan Luebbe 17 Jun '10

17 Jun '10

This fixes mangled ARFCN numbers in gsmtap. --- src/host/layer23/src/l1ctl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/host/layer23/src/l1ctl.c b/src/host/layer23/src/l1ctl.c index 051b3d8..5e683d3 100644 --- a/src/host/layer23/src/l1ctl.c +++ b/src/host/layer23/src/l1ctl.c @@ -165,7 +165,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) /* send CCCH data via GSMTAP */ gsmtap_chan_type = chantype_rsl2gsmtap(chan_type, dl->link_id); - gsmtap_sendmsg(dl->band_arfcn, chan_ts, gsmtap_chan_type, chan_ss, + gsmtap_sendmsg(ntohs(dl->band_arfcn), chan_ts, gsmtap_chan_type, chan_ss, tm.fn, dl->rx_level-110, dl->snr, ccch->data, sizeof(ccch->data)); -- 1.7.1

2 1

Thank you
by Zaki Ud Din 17 Jun '10

17 Jun '10

Hello, I am just writing this email to thank everyone who helped me with all the trouble I had while Osmocom. Though I didn't succeed in my objective but it was just a part of my project that I started quite late and was always fighting against time to complete it. Thank you :), Zaki.

2 1

Fwd: SIM card driver
by Drasko DRASKOVIC 11 Jun '10

11 Jun '10

Hi all, can anybody point be to the SIM card driver sources ? I looked at src/target/firmware/calypso but did not find it... Is there some other sources that you know for SCI (Smart Card Interface) that I can look at ? Best regards, Drasko ---------- Forwarded message ---------- From: Wolfgang Draxinger <wdraxinger.maillist(a)draxit.de> Date: Wed, Jun 9, 2010 at 10:08 AM Subject: Re: SIM card driver To: hardware(a)lists.openmoko.org, Al Johnson <openmoko(a)mazikeen.demon.co.uk> On Wed, 9 Jun 2010 00:04:07 +0200 Drasko DRASKOVIC <drasko.draskovic(a)gmail.com> wrote: > Very uncool :(. > > I need to write a driver for ARM PrimeCell Smart Card Interface PL131 > in order to init/read/write SIM card for 4G mobile device. Does > anybody knows where I can get hold of some implementation of (any) SIM > interface driver ? > > Thanks and BR, > Drasko SIMs, like any other SmartCard communicate over an interface very similar to I2C, with the notable difference, that the terminal always is the "bus" master. Building your very own SmartCard terminal is very easy. Or you just use one of the ready to use ones (from Towitoko, Reiner SCT, etc.). Also have a look in the Open Baseband project http://bb.osmocom.org/trac/ Which b nature also must deal with SIM cards. Wolfgang _______________________________________________ hardware mailing list hardware(a)lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware

2 2

Re:Trouble building Osmocom
by Zaki Ud Din 09 Jun '10

09 Jun '10

Hello, Thank you for your reply. I have downloaded the toolchain that I should have done at the first place. I am not getting those errors any more but I am stuck at some new ones. I am pasting them below ................. calypso/libcalypso.a(uart.o):(.ARM.exidx.text.uart_irq_handler_sercomm+0x0): undefined reference to `__aeabi_unwind_cpp_pr1' calypso/libcalypso.a(uart.o):(.ARM.exidx.text.uart_init+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_pull+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.__cons_rb_append+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_append+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_puts+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_flush+0x0): more undefined references to `__aeabi_unwind_cpp_pr0' follow make[1]: *** [board/compal_e88/hello_world.ramload.elf] Error 1 make[1]: Leaving directory `/home/zaki/osmocom-bb/src/target/firmware' make: *** [firmware] Error 2 Another thing that I had to ask was that basically my work is at the layer1 and all the c files present in that folder of firmware have got built, the error that is coming above is in some other folder. Would I be able to load the layer1 files through osmocon without completing the installation of the rest of the firmware. Awaiting your response, Zaki.

1 0

Getting Started with openmoko
by saravanan T 09 Jun '10

09 Jun '10

Hi, I would like to get started with osmocon for openmoko devices. I have checked out the project and setup the gnuarm but it doesnt seem to compile. I am running ubuntu karmic. Please do help me with the steps of getting it running on this device. -------------Error-------------- configure error could not find install.sh, or sh-tool make [shared/libosmocore/build-host/Makefile] -------------Error-------------- Regards Saravanan.L

3 2

Re: baseband-devel Digest, Vol 5, Issue 7
by Zaki Ud Din 09 Jun '10

09 Jun '10

Hello, I never thought I would become such a popular figure on your mailing lists, be it for the wrong reasons. I am sorry to have emailed you that question, but honestly I am new to Ubuntu. I have done quite a lot of programming on Windows, but this seems to be quite a different world, and that is why I email you even my seemingly childish questions for you to you, as I am sure you wont have any trouble solving them although it does takes some seconds of yours. Regards, Zaki. On Wed, Jun 9, 2010 at 9:47 AM, <baseband-devel-request(a)lists.osmocom.org>wrote: > Send baseband-devel mailing list submissions to > baseband-devel(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request(a)lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Re: Trouble building Osmocom (Sylvain Munaut) > 2. Re: Trouble building Osmocom (Zaki Ud Din) > 3. Re: Trouble building Osmocom (Huseyin Turan) > 4. Re: Trouble building Osmocom (Nordin) > 5. Re: Trouble building Osmocom (Huseyin Turan) > 6. Re: Trouble building Osmocom (Nordin) > 7. Re: Trouble building Osmocom (Nordin) > 8. Re: Trouble building Osmocom (Sylvain Munaut) > 9. Re: Trouble building Osmocom (Holger Hans Peter Freyther) > > > ---------- Forwarded message ---------- > From: Sylvain Munaut <246tnt(a)gmail.com> > To: > Date: Tue, 8 Jun 2010 15:57:22 +0200 > Subject: Re: Trouble building Osmocom > Looking at gnuarm.com, it looks like you have a x86_64 toolchain and > try to run it on i686. > Honestly I don't want to be mean but if you can't see what's wrong > with that, osmocom-bb might not be for you quite just yet. > > > > > ---------- Forwarded message ---------- > From: Zaki Ud Din <fyproject14(a)gmail.com> > To: baseband-devel(a)lists.osmocom.org > Date: Tue, 8 Jun 2010 19:00:20 +0500 > Subject: Re: Trouble building Osmocom > Hello, > > Thank you for your reply. I am really sorry I did not get your point in the > mail where you asked me to perform the different checks. Though I have > written those commands and have pasted their output below. > > > zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc > ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped > zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a > Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC > 2009 i686 GNU/Linux > > Awaiting your response, > > Zaki. > > > ---------- Forwarded message ---------- > From: Huseyin Turan <huseyinturan(a)gmail.com> > To: baseband-devel(a)lists.osmocom.org > Date: Tue, 8 Jun 2010 16:51:06 +0300 > Subject: Re: Trouble building Osmocom > Sorry; > > file ./arm-elf-gcc > ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped > > > > ---------- Forwarded message ---------- > From: Nordin <bouchtaoui(a)gmail.com> > To: baseband-devel(a)lists.osmocom.org > Date: Tue, 08 Jun 2010 16:26:08 +0200 > Subject: Re: Trouble building Osmocom > On 8-6-2010 15:57, Sylvain Munaut wrote: > >> Honestly I don't want to be mean but if you can't see what's wrong >> with that, osmocom-bb might not be for you quite just yet. >> >> > > Maybe he's good in programming embedded stuff, this has purely to do with > Linux specific builds and nothing to do with coding/decoding gsm stuff. > By the way, he can always learn... > > > > > > ---------- Forwarded message ---------- > From: Huseyin Turan <huseyinturan(a)gmail.com> > To: baseband-devel(a)lists.osmocom.org > Date: Tue, 8 Jun 2010 18:16:50 +0300 > Subject: Re: Trouble building Osmocom > Thank you very much. > > I have succeded to compile. I will try to deploy on C118. > > > ---------- Forwarded message ---------- > From: Nordin <bouchtaoui(a)gmail.com> > To: Sylvain Munaut <246tnt(a)gmail.com> > Date: Tue, 08 Jun 2010 17:24:35 +0200 > Subject: Re: Trouble building Osmocom > Silvain, > > Yes I agree with you, but I just want to note that we have to encourage > beginners to keep trying and learning. > Especially when one comes from the Windows world like me, where everything > builds magically in Visual Studio (debugging is a joy in there ;-) > Never programmed in Linux, never used git, gdb, vim, etc... and now, I > begin to rock a little bit, thnx to OpenBSC and you guys ;-) > > > > On 8-6-2010 17:07, Sylvain Munaut wrote: > >> Maybe he's good in programming embedded stuff, this has purely to do with >>> Linux specific builds and nothing to do with coding/decoding gsm stuff. >>> >>> >> I never meant otherwise in my previous message. But basic knowledge / >> problem solving of the build system is a requirement IMHO, especially >> in this project (that includes both host and target code with even >> some shared code between the two). >> >> I also looked up his history on the various mailing lists before >> posting this and this is not the first build problem with GSM related >> projects so I would expect him to learn from previous experience. >> >> >> Also, when I see a message with : >> >> ---- >> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc >> ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), >> dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped >> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a >> Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 >> 01:57:59 UTC 2009 i686 GNU/Linux >> ---- >> >> And he still asks what's wrong ? An embedded programmer that doesn't >> know he can't just run binaries from one architecture onto another >> architecture ... >> >> >> >> >> >>> By the way, he can always learn... >>> >>> >> I know, that's why there is a "quite just yet" at the end. That's >> exactly what I implied: that he learns that first and then come back. >> >> >> Cheers, >> >> Sylvain >> >> >> > > > > > > ---------- Forwarded message ---------- > From: Nordin <bouchtaoui(a)gmail.com> > To: baseband-devel(a)lists.osmocom.org > Date: Tue, 08 Jun 2010 17:27:53 +0200 > Subject: Re: Trouble building Osmocom > Congratulations! :) > > > > On 8-6-2010 17:16, Huseyin Turan wrote: > >> Thank you very much. >> >> I have succeded to compile. I will try to deploy on C118. >> >> >> > > > > > > ---------- Forwarded message ---------- > From: Sylvain Munaut <246tnt(a)gmail.com> > To: Nordin <bouchtaoui(a)gmail.com> > Date: Tue, 8 Jun 2010 17:07:42 +0200 > Subject: Re: Trouble building Osmocom > > Maybe he's good in programming embedded stuff, this has purely to do with > > Linux specific builds and nothing to do with coding/decoding gsm stuff. > > I never meant otherwise in my previous message. But basic knowledge / > problem solving of the build system is a requirement IMHO, especially > in this project (that includes both host and target code with even > some shared code between the two). > > I also looked up his history on the various mailing lists before > posting this and this is not the first build problem with GSM related > projects so I would expect him to learn from previous experience. > > > Also, when I see a message with : > > ---- > zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc > ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped > zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a > Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 > 01:57:59 UTC 2009 i686 GNU/Linux > ---- > > And he still asks what's wrong ? An embedded programmer that doesn't > know he can't just run binaries from one architecture onto another > architecture ... > > > > > By the way, he can always learn... > > I know, that's why there is a "quite just yet" at the end. That's > exactly what I implied: that he learns that first and then come back. > > > Cheers, > > Sylvain > > > > > ---------- Forwarded message ---------- > From: Holger Hans Peter Freyther <holger(a)freyther.de> > To: baseband-devel(a)lists.osmocom.org > Date: Wed, 09 Jun 2010 12:31:46 +0800 > Subject: Re: Trouble building Osmocom > On 06/08/2010 11:24 PM, Nordin wrote: > > Silvain, > > > > Yes I agree with you, but I just want to note that we have to encourage > > beginners to keep trying and learning. > > Especially when one comes from the Windows world like me, where > > everything builds magically in Visual Studio (debugging is a joy in > > there ;-) > > Never programmed in Linux, never used git, gdb, vim, etc... and now, I > > begin to rock a little bit, thnx to OpenBSC and you guys ;-) > > Hi Nordin, > > I wouldn't have the skills I have now if it wouldn't be due to others > help. And of course I know file and uname and it is new to others. The > biggest problem I have is judging is someone is just lazy, or if there > is someone who is slow to start but eager to learn. > > how would you figure that out? > > z. > > PS: Would you be willing to help me to go through the documentation and > provide some more getting started information? At least two have > downloaded a wrong toolchain, I am pretty sure this will happen again. > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel(a)lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > >

2 1

Re: Trouble building Osmocom
by Zaki Ud Din 08 Jun '10

08 Jun '10

Hello, Thank you for your reply. I am really sorry I did not get your point in the mail where you asked me to perform the different checks. Though I have written those commands and have pasted their output below. zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux Awaiting your response, Zaki.

1 0

Re: baseband-devel Digest, Vol 5, Issue 5
by Zaki Ud Din 08 Jun '10

08 Jun '10

Hello, Thank you very much for your reply. When i give the path to arm-elf-gcc "export PATH=$PATH:/home/zaki/gnuarm-4.0.2/bin/" , and run "make firmware", I get errors. I have pasted some of the errors that i get in config.log below and have also attached that file. configure:2559: checking for arm-elf-linux-gcc configure:2586: result: arm-elf-gcc configure:2858: checking for C compiler version configure:2866: arm-elf-gcc --version >&5 ../configure: line 2868: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2870: $? = 126 configure:2877: arm-elf-gcc -v >&5 ../configure: line 2879: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2881: $? = 126 configure:2888: arm-elf-gcc -V >&5 ../configure: line 2890: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2892: $? = 126 configure:2915: checking for C compiler default output file name configure:2937: arm-elf-gcc -Os -ffunction-sections -I../../../../target/firmware/include conftest.c >&5 ../configure: line 2939: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2941: $? = 126 configure:2979: result: configure: failed program was: Awaiting your response, Zaki. On Tue, Jun 8, 2010 at 6:12 PM, <baseband-devel-request(a)lists.osmocom.org>wrote: > Send baseband-devel mailing list submissions to > baseband-devel(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request(a)lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Re: Trouble building Osmocom (Adrian-Ken Rueegsegger) > 2. Re: Trouble building Osmocom (Sylvain Munaut) > 3. AW: Trouble building Osmocom (Riemer, Bjoern) > 4. Re: Trouble building Osmocom (Holger Freyther) > 5. Trouble building Osmocom (Zaki Ud Din) > 6. Re: Trouble building Osmocom (Holger Freyther) > > > ---------- Forwarded message ---------- > From: Adrian-Ken Rueegsegger <ken(a)codelabs.ch> > To: Zaki Ud Din <fyproject14(a)gmail.com> > Date: Tue, 08 Jun 2010 12:44:56 +0200 > Subject: Re: Trouble building Osmocom > Hi, > > Zaki Ud Din schrieb: > > Hello, > > > > Thank you very much for your reply. No my config.log file seems to be > > different. I am pasting a portion of config.log file below and am also > > attaching the complete file with this email. > > [snip] > > > configure:2866: arm-elf-gcc --version >&5 > > ../configure: line 2868: arm-elf-gcc: command not found > > configure:2870: $? = 127 > > configure:2877: arm-elf-gcc -v >&5 > > ../configure: line 2879: arm-elf-gcc: command not found > > configure:2881: $? = 127 > > configure:2888: arm-elf-gcc -V >&5 > > ../configure: line 2890: arm-elf-gcc: command not found > > configure:2892: $? = 127 > > configure:2915: checking for C compiler default output file name > > configure:2937: arm-elf-gcc -Os -ffunction-sections > > -I../../../../target/firmware/include conftest.c >&5 > > ../configure: line 2939: arm-elf-gcc: command not found > > It does not find the toolchain/cross-compiler. Where did you > install/unpack the toolchain? Please check that it is really in > "/gnuarm-4.0.2/arm-elf/bin". Otherwise you have to export the proper path. > > -Adrian > > > > > ---------- Forwarded message ---------- > From: Sylvain Munaut <246tnt(a)gmail.com> > To: baseband-devel(a)lists.osmocom.org > Date: Tue, 8 Jun 2010 12:43:19 +0200 > Subject: Re: Trouble building Osmocom > This seems pretty clear : > > > ../configure: line 2939: arm-elf-gcc: command not found > > Make sure you have a good ARM toolchain installed ... (look it up on > google, plenty of doc on how to install one). > > Sylvain > > > > > ---------- Forwarded message ---------- > From: "Riemer, Bjoern" <bjoern.riemer(a)fokus.fraunhofer.de> > To: "Zaki Ud Din" <fyproject14(a)gmail.com>, < > baseband-devel(a)lists.osmocom.org> > Date: Tue, 8 Jun 2010 13:07:30 +0200 > Subject: AW: Trouble building Osmocom > > Hi > > > > You say that you unpacked the gcc compiler to your home directory and then > set you path to PATH=/gnuarm-4.0.2/arm-elf/bin:$PATH .. > > Unless your home directory is set to / the path to the gcc compiler is > wrong. > > > > bjoern > > > > *Von:* baseband-devel-bounces(a)lists.osmocom.org [mailto: > baseband-devel-bounces(a)lists.osmocom.org] *Im Auftrag von *Zaki Ud Din > *Gesendet:* Sonntag, 6. Juni 2010 22:21 > *An:* baseband-devel(a)lists.osmocom.org > *Betreff:* Trouble building Osmocom > > > > Hello, > > I have been trying to build osmocom but have been getting errors in doing > so. > > Firstly, I downloaded the following file,"* binutils-2.16.1, > gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under > GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home > folder. > > Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/ > > bin:$PATH" in terminal window. Afterwards when I entered "make" under > "/osmosom-bb/src", I got the following errors > > > zaki@zaki-desktop:~/osmocom-bb/src$ make > > cd shared/libosmocore/build-host && make > make[1]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make all-recursive > make[2]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > Making all in include > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in osmocore > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > Making all in protocol > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Nothing to be done for `all'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[5]: Nothing to be done for `all-am'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in src > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > Making all in tests > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > Making all in timer > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > Making all in sms > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[2]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[1]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > cd shared/libosmocore/build-target && ../configure \ > --host=arm-elf-linux --disable-shared --disable-talloc > --disable-tests \ > CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections > -I../../../../target/firmware/include" > configure: WARNING: If you wanted to set the --build type, don't use > --host. > If a cross compiler is detected then cross compile mode will be used. > > > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking for arm-elf-linux-strip... no > checking for strip... strip > checking whether make sets $(MAKE)... (cached) yes > > > checking for arm-elf-linux-gcc... arm-elf-gcc > checking for C compiler default output file name... > configure: error: in > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-target': > configure: error: C compiler cannot create executables > See `config.log' for more details. > make: *** [shared/libosmocore/build-target/Makefile] Error 77 > > I shall be grateful to you if you could help me on this. > > Awaiting your Response, > > Zaki. > > > ---------- Forwarded message ---------- > From: Holger Freyther <zecke(a)selfish.org> > To: > Date: Tue, 08 Jun 2010 20:05:45 +0800 > Subject: Re: Trouble building Osmocom > On 06/08/2010 07:59 PM, Zaki Ud Din wrote: > > Hello, > > > I did export the path using the following line "export > > PATH=$PATH:/home/zaki/gnuarm- > > 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got > > the errors I told you. > > > > Awaiting your response, > > Well, > it claims to not find arm-elf-gcc. Have you considered checking that > this application exists? e.g. does which arm-elf-gcc lead to anything? > > > > > > > > ---------- Forwarded message ---------- > From: Zaki Ud Din <fyproject14(a)gmail.com> > To: baseband-devel(a)lists.osmocom.org, Holger Freyther <zecke(a)selfish.org> > Date: Tue, 8 Jun 2010 16:59:23 +0500 > Subject: Trouble building Osmocom > Hello, > > Thank you very much for your reply. > > I am using ,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, > insight-6.4, TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from > www.gnuarm.com. I then extracted to the folder named "Zaki". > > I did export the path using the following line "export > PATH=$PATH:/home/zaki/gnuarm- > 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got > the errors I told you. > > Awaiting your response, > > Zaki. > > ---------- Forwarded message ---------- > From: Holger Freyther <zecke(a)selfish.org> > To: baseband-devel(a)lists.osmocom.org > Date: Tue, 08 Jun 2010 21:12:05 +0800 > Subject: Re: Trouble building Osmocom > On 06/08/2010 09:01 PM, Huseyin Turan wrote: > > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: in > > `/home/name1/osmocom/osmocom-bb/src/shared/libosmocore/build-host': > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > Looking at the log file is always a good idea. It might have an eye > opening effect.... > > > > > > That is; in gnuarm-4.0.2/arm-elf/bin there are executables like > > gcc,g++,etc. which can be executed. > > in gnuarm-4.0.2/bin there are executables like > > arm-elf-gcc,arm-elf-g++,etc. which can not be executed. > > > > Which path is true? > > You want to use your normal gcc and such, so putting > gnuarm-4.0.2/arm-elf/bin in your path is not that clever. What is the > issue with arm-elf-gcc? What happens when you try to execute it? > > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel(a)lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > >

1 0

Re: Trouble building Osmocom
by Holger Freyther 08 Jun '10

08 Jun '10

On 06/08/2010 09:24 PM, Huseyin Turan wrote: > name1@name1-desktop:~/osmocom/gnuarm-4.0.2/bin$ ./arm-elf-gcc > bash: ./arm-elf-gcc: cannot execute binary file Why is that the case? The basic checks are a.) did the +x bit go missing on that file? b.) file ./arm-elf-gcc tells you what architecture is that? uname -a tells you what architecture are you running on? c.) when the above fails, we will talk about it...

1 0

Re: Trouble building Osmocom
by Holger Freyther 08 Jun '10

08 Jun '10

On 06/08/2010 09:01 PM, Huseyin Turan wrote: > checking for gcc... gcc > checking for C compiler default output file name... > configure: error: in > `/home/name1/osmocom/osmocom-bb/src/shared/libosmocore/build-host': > configure: error: C compiler cannot create executables > See `config.log' for more details. Looking at the log file is always a good idea. It might have an eye opening effect.... > > That is; in gnuarm-4.0.2/arm-elf/bin there are executables like > gcc,g++,etc. which can be executed. > in gnuarm-4.0.2/bin there are executables like > arm-elf-gcc,arm-elf-g++,etc. which can not be executed. > > Which path is true? You want to use your normal gcc and such, so putting gnuarm-4.0.2/arm-elf/bin in your path is not that clever. What is the issue with arm-elf-gcc? What happens when you try to execute it?

1 0

Trouble building Osmocom
by Zaki Ud Din 08 Jun '10

08 Jun '10

Hello, Thank you very much for your reply. I am using ,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from www.gnuarm.com. I then extracted to the folder named "Zaki". I did export the path using the following line "export PATH=$PATH:/home/zaki/gnuarm- 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got the errors I told you. Awaiting your response, Zaki.

2 1

Trouble building Osmocom
by Zaki Ud Din 08 Jun '10

08 Jun '10

Hello, I have been trying to build osmocom but have been getting errors in doing so. Firstly, I downloaded the following file,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home folder. Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/ bin:$PATH" in terminal window. Afterwards when I entered "make" under "/osmosom-bb/src", I got the following errors zaki@zaki-desktop:~/osmocom-bb/src$ make cd shared/libosmocore/build-host && make make[1]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make all-recursive make[2]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' Making all in include make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' Making all in osmocore make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' Making all in protocol make[5]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' make[5]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' Making all in src make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' Making all in tests make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' Making all in timer make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' Making all in sms make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[2]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[1]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --disable-shared --disable-talloc --disable-tests \ CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections -I../../../../target/firmware/include" configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for arm-elf-linux-strip... no checking for strip... strip checking whether make sets $(MAKE)... (cached) yes checking for arm-elf-linux-gcc... arm-elf-gcc checking for C compiler default output file name... configure: error: in `/home/zaki/osmocom-bb/src/shared/libosmocore/build-target': configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [shared/libosmocore/build-target/Makefile] Error 77 I shall be grateful to you if you could help me on this. Awaiting your Response, Zaki.

5 8

Re: Trouble building Osmocom
by Sylvain Munaut 08 Jun '10

08 Jun '10

This seems pretty clear : > ../configure: line 2939: arm-elf-gcc: command not found Make sure you have a good ARM toolchain installed ... (look it up on google, plenty of doc on how to install one). Sylvain

1 0

General Info
by Micheal Johnson 07 Jun '10

07 Jun '10

Hello, Can this project be used to transmit gsm packets from the mobile phone? Regards, Micheal.

1 0

state of layer23
by Andreas.Eversberg 07 Jun '10

07 Jun '10

hi, if you pull the git, you will notice that i submitted the lapdm code i was working on. location update with app_mobile works now. (at least for the combined BCCH+CCCH+SDCCH4) the best way to test the location update is to setup a mobile test card to manual network selection, and to set the registered PLMN to the tester's network. see VTY interface for more. what happens: - the previously store ba-list of frequencies is used to search for the registered PLMN. since there is only one frequency on a tester, the power measurement is done on this frequency only. - the power measurement result is positive, so a sync request is made to that channel. - the sync is indicated by layer 1. - the BCCH data is received. the cell is "suitable and allowable". - a sync request is done again, because this cell is the one to "camp on". - a sync request is done again, because the mobility management process makes a location update and requests a channel from the radio ressource. - the sync is confirmed by layer 1. - after syncing to the channel the layer 2 is activated by the BTS. - the location updating request is sent and messages are exchanged until the location update is complete. - the layer 2 is de-activated by the BTS. - the release of layer 2 is currently not processed by RR, so the timout aborts the radio link. (but this is fixed soon) but there are problem: 1. the layer 1 sometimes crashes when sending frames. i guess there is no queue inside... i currently don't care about any confirm of a frame, so i send all frames i need to send. i would like to get a confirm when a frame is sent, so i can send the next frame without making layer 1 overflow. this confirm would also be handy for RACH requests when they are sent. since there are only few message during a location update or a call, i think this is not much overhead. when requesting sync/rach again, all pending frames (RACH request / transmit data) shall be removed inside layer 1. 2. when sending two sync requests to layer 1 without a delay, the layer 1 crashes. i expect to do a sync request at any time. also when sending a sync request before i got a response, i do not know to which the response belongs to which request. (delayed on the serial line) a confirm of every sync request would be handy, so i can wait for this confirm until i make another sync request to a different channel. this confirm just tells me that the layer 1 has received the sync request and is able to receive another sync request. also when syncing to a different channel, i skip any sync result or received frames until i get the confirm, so i can skip any data from the last channel i was synced to. andreas

1 0

Building Osmocom
by Zaki Ud Din 06 Jun '10

06 Jun '10

Hello, I am a little new to ubuntu and am trying to build osmocom-bb but i am facing some problems in doing so. I found your emial address in the .c files present in the Osmocom-bb folder. I have downloaded the GNU toolchain for ARM which is the first step in building Osmocom. But I am not able to understand the second step in which I have to set a path to include the arm-elf-* executables of the toolchain. Would you please help me on this? Awaiting your response, Zaki.

4 3

Finally... FB/SB Layer1 changes working/merged
by Harald Welte 20 May '10

20 May '10

Hi all! I've merged a number of layer1 related changes that I've been working on for quite some time. The major difference is: there is no L1CTL_NEW_CCCH_REQ anymore, it has been replaced by L1CTL_FBSB_REQ. When issuing FBSB_REQ, you can specify what tasks you want the layer1 to perform (any bitmask of FB0, FB1, SB). Also, if the acquisition fails completely, you will get a L1CTL_FBSB_RESP with result=0xff. This means there is now proper error reporting. Let's say you want a relatively quick indication if the ARFCN specified could at all be a BCCH, then issuing FBSB_REQ only with FB0 should return even more quickly. You will definitely get a response after some 15 TDMA frames if there was a frequency burst or not. Furthermore, I have changed some details of the FB/SB acquisition process: Rather than waiting for a fixed amount (500) TDMA frames before switching from FB0->FB1 or FB1->SB, the switch is now done based on thesholds for frequency delta and SNR. The frequency thresholds can actually be specified by L1CTL, the SNR thresholds are hardcoded. One problem with fast scanning was that by erroneous FB0 reports, we tuned our VCO so far off the desired frequency that it never synced to any cell at all anymore. I have reduced that problem by simply resetting the AFC-DAC to its default value every time we start a FBSB acquisition. Andreas: I think it would make sense to use the S_L1CTL_FBSB_RESP and S_L1CTL_FBSB_ERR signals in 'mobile', especially if you receive an _ERR, you can immediately switch to the next ARFCN without wasting further time. My next API change will be to introduce a separate command, i.e. FBSB_REQ will no longer start the multiframe task for BCCH NORMAL/EXTENDED, but the application will have to explicitly request that. However, I don't think I'll find much time throughout the next 10 days or so.. .sorry :/ 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: [PATCH 2/2] Add new board gta0x (for Openmoko Freerunner devices) and build it
by Nico Golde 19 May '10

19 May '10

Hi, * Daniel Willmann <daniel(a)totalueberwachung.de> [2010-05-17 11:48]: > For now just copied over the compal_e88 init.c and adapted the RF > frontend functions. For osmocon to work with the GSM download cable > SERCOMM_UART_NR and CONS_UART_NR need to be switched. [...] > +/* describe how the RF frontend is wired on the Openmoko GTA0x boards */ > + > +#define RITA_RESET TSPACT(0) /* Reset of the Rita TRF6151 */ > +#define PA_ENABLE TSPACT(9) /* Enable the Power Amplifier */ > +#define GSM_TX TSPACT(3) /* PA GSM switch, low-active */ > + > +/* All VCn controls are low-active */ > +#define ASM_VC1 TSPACT(2) /* Antenna switch VC1 */ > +#define ASM_VC2 TSPACT(1) /* Antenna switch VC2 */ > +#define ASM_VC3 TSPACT(4) /* Antenna switch VC3 */ > + > +#define IOTA_STROBE TSPEN0 /* Strobe for the Iota TSP */ > +#define RITA_STROBE TSPEN2 /* Strobe for the Rita TSP */ > + > +/* switch RF Frontend Mode */ > +void rffe_mode(enum gsm_band band, int tx) > +{ > + uint16_t tspact = tsp_act_state(); > + > + /* First we mask off all bits from the state cache */ > + tspact &= ~PA_ENABLE; > + tspact |= GSM_TXEN; /* low-active */ [...] I'm not sure what the correct value is in this case but GSM_TXEN is not defined at this point. Cheers Nico

4 3

[PATCH 1/2] osmocon: extend hexdump to show all printable characters
by Jan Luebbe 19 May '10

19 May '10

--- src/host/osmocon/osmocon.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index b823b5b..4ad48e2 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -22,6 +22,7 @@ * */ +#include <ctype.h> #include <stdio.h> #include <stdlib.h> #include <string.h> @@ -418,11 +419,16 @@ int read_file(const char *filename) static void hexdump(const uint8_t *data, unsigned int len) { - const uint8_t *bufptr = data; int n; - for (n=0; n < len; n++, bufptr++) - printf("%02x ", *bufptr); + for (n=0; n < len; n++) + printf("%02x ", data[n]); + printf(" "); + for (n=0; n < len; n++) + if (isprint(data[n])) + putchar(data[n]); + else + putchar('.'); printf("\n"); } -- 1.7.1

2 2

[PATCH 0/2] Add gta0x board support
by Daniel Willmann 17 May '10

17 May '10

Hello, these patches enable osmocom to be run on the Openmoko GTA0x devices (only tested with GTA02). The first patch fixes an issue with baudrate setting in osmocon.c (termios setting wasn't read prior to writing). The second patch adds a gta0x board (currently only copied from compal_e88) and implements the differences in controlling the RF frontend. Use it as follows (on the device): kill all processes communicating with the modem (fso, gsm0710muxd) gta02# echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/download Then on the PC connect the download cable and start osmocon: # ./osmocon -m romload -p /dev/ttyUSB0 ../../target/firmware/board/gta0x/l1test.osmoload.bin To initiate the download toggle baseband power on the phone: gta02# echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on && > echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on After the firmware is transferred the app should start. Regards, Daniel Willmann Daniel Willmann (2): osmocon.c: Fix serial_set_baudrate function Add new board gta0x (for Openmoko Freerunner devices) and build it src/host/osmocon/osmocon.c | 5 + src/target/firmware/Makefile | 4 +- .../firmware/board/common/rffe_gta0x_triband.c | 88 +++++++++++++ src/target/firmware/board/gta0x/init.c | 131 ++++++++++++++++++++ 4 files changed, 227 insertions(+), 1 deletions(-) create mode 100644 src/target/firmware/board/common/rffe_gta0x_triband.c create mode 100644 src/target/firmware/board/gta0x/init.c

1 0

MTK status update
by Steve Markgraf 16 May '10

16 May '10

Hi all, I wanted to give a short status update on the MTK platform, I spent the last day implementing a minimal subset of the MTK romloader protocol in osmocon. We can now run our own C-code on the MT622x, I started by modifying the linker script and run proms loader (because it doesn't need interrupts, the interrupt redirection isn't yet figured out). When writing something to the UART TX register, I see the output in osmocon, and writing to the Baseband powerup register works as well (otherwise you would have to hold down the power-button all the time). Unfortunately there are no schematics for the Mobistel phone I've been testing this with, so I haven't found out how to enable e.g. the backlight, nothing happens when activating PWM1/2. Today I tried to modify the Calypso UART driver for the MTK UART, but currently I'm stuck with a strange hang somewhere in the driver, maybe I'll look after it tomorrow. That was it for the moment... Regards, Steve

2 1

Newbie + questions: C123 and Racal 6103
by Joerg Albert 15 May '10

15 May '10

Hi, I've recently got pointed to this project. Haven't dealt with any GSM software since the mid-90ies, so I thought it may be some fun to look at the software and participate if I find enough time. I've got access to a Racal 6103 and a C123 to start with. A couple of questions: 1) Do I need attenuators if I wire the C123 to the Racal? Guess not, but I don't want to fry the input of the Racal. 2) External antenna connector on the C123 seems to be a MS-147. I got a couple of HF cables from a WLAN card with this connector: http://shop.meconet.de/artikeldet.php?suchspeicher=110448&proid=550&bez=Cri… but the inner conductor of the plug seems to be a bit short (may be my fault during assembly). Does the MS-147 jack on the C123 switch off the internal antenna if anything is plugged in? 3) Does the PA of the C123 survive without any antenna connected (i.e. if it gets most of the HF reflected back) e.g. in continuous transmit mode? 4) A C123 without battery doesn't start the vendor firmware, display is blank, LED are on, flicker from time to time. Is this a hardware problem or just the vendor firmware missing the battery, i.e. any problem to download osmocom software without any battery? Thanks for any answers!

2 1

PATCH: 5x8 font
by Christian Vogel 14 May '10

14 May '10

Hi, I converted the X font 5x8 for use in BB and added an goto_xy routine in case anyone wants to put something entertaining on the LCD (besides Hello World). Compared to the old 8x8 font.. - doesn't miss the topmost line of pixels :-) - needs 475 bytes instead of 4k (only includes characters ASCII 32 .. 126) - allows for 19x8 characters on the screen hello_world.bin prints out all glyphs for testing. Applies to current "master" (as of 9.4.2010/15:30 MESZ). Chris

6 11

update on layer 3 work
by Andreas.Eversberg 13 May '10

13 May '10

hi, i like to give a short update: currently i am testing the processes of selecting a cell and the network. the processes depend on the coverage, the sim card (network, inserted or not) and the mode (manual or automatic network selection). i hope i will finish this week. to configure mode and sim card and other parameters in the future, i use the VTY, you already know from the OpenBSC project. there you can get informations about the subscriber, the mobile station and the received cells (system informations). i will move all hacked parameters (test sim) to VTY config file. manual network selection mode requires reaction of the user, so it will also be added to the VTY. later the VTY can also command the "call" part to dial, answer and hangup a call. my idea: later these VTY command structure may be used for the phone's menu (up - down - enter - escape), if compiled appropiate. also: if layer 3 is running on the phone, the serial port could directly connect to the VTY, so the phone gets a console interface for debugging and faster configuration. currently the process (with sim card) ends while trying to do a location update. if the given channel is not supported, the program exits. to prevent this, just keep radio TX feature disable. the cell will be re-selected again and again (hopefully if the process works correct). sometimes, especially at the first run, the radio process stops. (no results for measurements, no sync to selected frequency.) also there is something i am wondering: calibration especially for the burst signal phase is measured and then stored on the eeprom by the manufacturer. do we use it? or do we need to do our own calibration? regards, andreas

2 2

public project with MTK baseband firmware project
by Harald Welte 10 May '10

10 May '10

Hi all! In case you're interested, there seems to be a public project on code.google.com that contains the build environment and baseband firmware sdk from mediatek: svn checkout http://mobile-phone-mtk-project.googlecode.com/svn mtk-project Please note that I don't know about the legality of this. However, it is distributed on a public server/service without any kind of authentication... 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)

7 13

Request for help with VCTCXO measurements
by Harald Welte 09 May '10

09 May '10

Hi all! Right now, one of our many issues in L1 is the frequency stability (or lack thereof). What we do right now is very primitive and is mostly based on guesswork, rather than measurements and good algorithms. In order to change this, we need some measurements to be done. As I am currently again travelling a lot, and my time for OsmocomBB is more limited now, I hope that somebody else will be able to take the measurements as described below. There is a big number of people in this project who now have a Racal 6103 (or similar) measurement device. Also, for those in Berlin, the CCC Berlin has one in its basement lab. What needs to be done: 1) Determine the relation between AFCDAC output and actual carrier frequency. All that is needed is some manual control over the AFCDAC value (e.g. based on keypad events) while the AFC is disabled. Then we continuously transmit bursts (content is unimportant) to the Racal 6103 and note the measured frequency error by the 6103 for every AFC value that we input. Those measurements should then be repeated for each supported band of the phone, preferrably each with a low-frequency channel, a medium frequency and a high-frequency channel. This means something like 10 different AFC values for 3 different channels of each of the 2 bands that the c123/c155 support. Basd on those measurements (preferrably do that series with 2-3 phones) we can construct a function that will tell us which AFCDAC value we should program if we want a given carrier frequency increase/decrease. 2) Determine the temperature related frequency drift and corresponding temperature ADC reading Especially when we transmit, the temperature in the RF section of the phone is assumed to change quite a bit. This means we need to measure the temperature in the oscillator (using the RITA-internal temperature sensor connected to one of the ADC channels of IOTA) and compare that with the frequency drift. In order to measure this, we first need a temperature-ADC driver. Once that exists, we can lock onto a BCCH, then make sure the AFC is disabled and the AFCDAC output value will be stable. Next, one can use e.g. a hairdryer or ice spray to change the temperature. While doing that, we can measure the difference in carrier frequency with the Racal 6103. The absolute temperature in centigrade/kelvin is not actually interesting to us all. All we want to know is: What is the 6103-measured frequency error at a given temperature-ADC-reading. Once again, the measurements should be done for high (1800) and low (900) band independently, just to be sure. Based on their relation we can also model a function, table or other approximation and include that in our AFC code. I think I'll be able to write the code even while I'm on the road - if somebody is able to do the measurements and post them to the mailing list. Thanks in advance, 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)

3 8

Osmoloader stored in Flash?
by Rust, Marco 03 May '10

03 May '10

Hello, I checkout the prom/loader AND prom/loader-crc part and merged it (perhaps I use git wrong way) When I run the loader with "osmcon -m c123xor" the loader starts but says "Failed to initialize flash". I tried to "romload" it with "-m romload" there only beacons but no valid response from phone. Sending beacon... Sending beacon... got 1 bytes from modem, data looks like: ff got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: ff Sending beacon... Sending beacon... Sending beacon... Sending beacon... 1. Why the flash initialization fails? 2. Is it (currently) possible to run programs (ex. L1test from flash)? I (think I)read all this rom/ram/bootloader stuff. ------------------------- Marco Rust FOKUS - Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin marco.rust(a)fokus.fraunhofer.de

4 6

I see cells
by Andreas.Eversberg 03 May '10

03 May '10

hi, tests with layer 3 pointed out a problem. when i select a cell, i get updates of system informations, paging requests and immediate assignments. after about half an hour, i get some corrupt frames. i don't know yet what is wrong. 1. is the communication between the layer 1 and layer 2 (over serial link) secure? 2. i must be sure that a message between layers always are: - never get lost (except unit-data or data when connection is aborted) - never are corrupt - received in the order they are sent 3. does layer 1 drop (bcch) frames, if they have biterrors? (as it should do) andreas

3 2

disable comitting of files
by Andreas.Eversberg 30 Apr '10

30 Apr '10

hi, i like to change some tracked files without committing them. when i do "git commit -a", every change is comitted. sometimes i like to play with layer1 code or even change Makefile.inc, but i don't want to reset my changes before committing. any idea how to create a list of omitted files? andreas

3 2

TODO list / Next project goals
by Harald Welte 29 Apr '10

29 Apr '10

Hi! I think we corrently have the following TODO list. GSM Layer 1: * implement transmit power control for transmit * implement SDCCH/8 on TS1-7 (Sylvain) * implement frequency hopping * proper split between synchronous and asynchronous part of L1 (Harald) * TCH/F support (Dieter, after L3 RR/MM/CC is working) * A5/1 and A5/2 encryption support GSM Layer 2: * implement a real layer2 that deserves the name (full LAPDm implementation) * properly encapsulate / abstract the L1 "MPH" primitives so L3 doesnt call L1 directly anymore GSM Layer 3: * test most of the code that Andreas has written (depends on L1 / L2) Misc: * SIM card driver + ISO7816 FS API * Battery charger driver * UI framework * minimal journalling flash file system * decide which RTOS kernel we want to use (Harald) * fully support a working firmware build for the openmoko gta01/gta02 GSM modem using calypso romloader For people who don't feel like they can take any of this work, there is some other work, regarding the mid-term port to our next target platform: * implement host utility for the medaitek MT622x romloader serial protocol * try to get a minimal hello world codebase to run on the MT622x * write hardware drivers for UART, PMU, I2C, SPI, ... of the MT622x 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)

5 4

Re: TODO list / Next project goals
by Dieter Spaar 28 Apr '10

28 Apr '10

Hello Harald, On Wed, 28 Apr 2010 20:26:07 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > GSM Layer 1: > * implement transmit power control for transmit > * implement SDCCH/8 on TS1-7 (Sylvain) > * implement frequency hopping > * proper split between synchronous and asynchronous part of L1 (Harald) > * TCH/F support (Dieter, after L3 RR/MM/CC is working) > * A5/1 and A5/2 encryption support I can take care of * implement frequency hopping * A5/1 and A5/2 encryption support in addition to * TCH/F support because this would fit together (just different setting on the GSM testset to do frequency hopping or encryption with a TCH). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

AW: not tuning to another bcch
by Andreas.Eversberg 28 Apr '10

28 Apr '10

> This is a known problem, but despite working from morning through night I > really don't have any time to fix the various layer1 issues at the moment, > sorry. In fact, there are some fundamental changes/cleanups required, and > I've already literally spent days in coming up with an architecture that seems > to make sense to me :/ > I know it must be frustrating for you, but it seems our schedules didn't match > very well. hi harald, i am currently testing the process of cell selection. when i limit the number of cells down to 1, i can test some parts of the process. don't worry about frustrating me. i can wait until these issues are solved. until then, there is so much more for me todo: - system information parsing test - testing location update procedure - working on incomplete radio ressource process - maybe start working on some layer 4 application (lcr interface) regards, andreas

1 0

not tuning to another bcch
by Andreas.Eversberg 27 Apr '10

27 Apr '10

hi, while debugging my layer3 code and testing bcch_scan, i got the following problem: the fist 'tuning' message L1CTL_NEW_CCCH_REQ to layer 1 works, system informations are received. subsequently tuning to another channel does not give any rx data. any idea? andreas Mit freundlichen Grüßen, .-. /'v'\ (/ \) ------------------------------------------------------------------"-"- |_| i.A. Andreas Eversberg Network Operations / 2nd Level Data - KC Internet Versatel Nord GmbH Nordstr. 2 D-24937 Flensburg Fon: +49-461-9099749 | Fax: +49-461-909960749 andreas.eversberg@versatel.de@versatel.de | www.versatel.de Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL Geschäftsführer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven

2 1

AW: Layer 3 status
by Andreas.Eversberg 26 Apr '10

26 Apr '10

> - 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.

1 0

AW: Layer 3 status
by Andreas.Eversberg 26 Apr '10

26 Apr '10

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

1 0

Layer 3 status
by Andreas.Eversberg 26 Apr '10

26 Apr '10

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

2 1

Re: Re: Off-by-one errors in Tx timing
by Dieter Spaar 26 Apr '10

26 Apr '10

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

1 0

Re: Off-by-one errors in Tx timing
by Dieter Spaar 25 Apr '10

25 Apr '10

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

2 1

Off-by-one errors in Tx timing
by Harald Welte 25 Apr '10

25 Apr '10

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)

2 2

PWT and PWL relation
by emersonv6 22 Apr '10

22 Apr '10

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.

1 0

backlight reg?
by emersonv6 22 Apr '10

22 Apr '10

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.

2 1

plabs prj
by emersonv6 22 Apr '10

22 Apr '10

Hi, plabs project seems to be removed from sf.net, did somebody mirror it or something? regards, emerson

2 1

How to grow and scale the project?
by Harald Welte 20 Apr '10

20 Apr '10

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)

4 3

large collection of gsm related datasheets
by willem 19 Apr '10

19 Apr '10

i found this, searching google/codesearch for 'ftm_cmd' svn co http://hwplatform.googlecode.com/svn/trunk/ about 1.5G of datasheets, sourcecode, and tools for various phones. willem

5 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel