From roytiberius at gmail.com Fri May 20 11:58:27 2011 From: roytiberius at gmail.com (Roy) Date: Fri, 20 May 2011 04:58:27 -0700 (PDT) Subject: hmm, sorry, data cable question In-Reply-To: <20110204075031.GH6627@prithivi.gnumonks.org> References: <20110204075031.GH6627@prithivi.gnumonks.org> Message-ID: <1305892707538-2965249.post@n3.nabble.com> I made this interface and it is 100% working! http://baseband-devel.722152.n3.nabble.com/file/n2965249/Motorola_T191_unlock_cable_interface_by_Roy.jpg -- View this message in context: http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-tp2419703p2965249.html Sent from the baseband-devel mailing list archive at Nabble.com. From wpatan at gmail.com Fri May 20 14:43:59 2011 From: wpatan at gmail.com (wpatan) Date: Fri, 20 May 2011 07:43:59 -0700 (PDT) Subject: hmm, sorry, data cable question In-Reply-To: <1305892707538-2965249.post@n3.nabble.com> References: <20110204075031.GH6627@prithivi.gnumonks.org> <1305892707538-2965249.post@n3.nabble.com> Message-ID: <1305902639585-2965845.post@n3.nabble.com> Please double check if your cable's output is 3.3v... this circuit could fry your phone. The output of MAX232 should not exceed 3.3v -- View this message in context: http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-tp2419703p2965845.html Sent from the baseband-devel mailing list archive at Nabble.com. From lokkju at gmail.com Fri May 20 17:00:19 2011 From: lokkju at gmail.com (Lokkju Brennr) Date: Fri, 20 May 2011 10:00:19 -0700 Subject: hmm, sorry, data cable question In-Reply-To: <1305902639585-2965845.post@n3.nabble.com> References: <20110204075031.GH6627@prithivi.gnumonks.org> <1305892707538-2965249.post@n3.nabble.com> <1305902639585-2965845.post@n3.nabble.com> Message-ID: With a 7805 and max232, it looks like it is probably 5v (the circuit is using the R2OUT/T2IN pins, which are Vcc, so 5v). A MAX3232 with something like a LM2940-3.3 would probably be a *much* better option, and give you real 3.3v. Loki On Fri, May 20, 2011 at 7:43 AM, wpatan wrote: > Please double check if your cable's output is 3.3v... this circuit could fry > your phone. > The output of MAX232 should not exceed 3.3v > > > -- > View this message in context: http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-tp2419703p2965845.html > Sent from the baseband-devel mailing list archive at Nabble.com. > > From roytiberius at gmail.com Tue May 24 12:49:45 2011 From: roytiberius at gmail.com (Roy) Date: Tue, 24 May 2011 05:49:45 -0700 (PDT) Subject: hmm, sorry, data cable question In-Reply-To: References: <20110204075031.GH6627@prithivi.gnumonks.org> <1305892707538-2965249.post@n3.nabble.com> <1305902639585-2965845.post@n3.nabble.com> Message-ID: <1306241385807-2979519.post@n3.nabble.com> these are my voltage measurements http://baseband-devel.722152.n3.nabble.com/file/n2979519/Motorola_T191_unlock_cable_interface_by_Roy_Volts_Measurement.jpg -- View this message in context: http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-tp2419703p2979519.html Sent from the baseband-devel mailing list archive at Nabble.com. From lbernal at gmail.com Tue May 24 13:04:52 2011 From: lbernal at gmail.com (n0p [Luis Bernal]) Date: Tue, 24 May 2011 15:04:52 +0200 Subject: hmm, sorry, data cable question In-Reply-To: <1306241385807-2979519.post@n3.nabble.com> References: <20110204075031.GH6627@prithivi.gnumonks.org> <1305892707538-2965249.post@n3.nabble.com> <1305902639585-2965845.post@n3.nabble.com> <1306241385807-2979519.post@n3.nabble.com> Message-ID: what serial port are you using? usb-serial? a laptop one? you are not frying your mobile only because you are lucky: your com port fails to deliver the 12~15v standard to the rs232 and delivers 5v instead so the 7805 regulator fails to deliver 5v because it's a linear regulator with a high drop out (internal voltage loss- it is designed to work at at least 6 or 7v ) plus the diodes voltage drop and it's delivering 3.4v if your connect that cable to a good com port, it will drive the calypso at 5v and it will fry it. right now is delivering 2.5v on tx, and it seems that's just enough to drive the calypso serial TL;DR: get a usb->ttl3.3v cable and forget this one also, did anyone tried attaching a phone to a 5v cable to see if it really dies? 2011/5/24 Roy > these are my voltage measurements > > > http://baseband-devel.722152.n3.nabble.com/file/n2979519/Motorola_T191_unlock_cable_interface_by_Roy_Volts_Measurement.jpg > > -- > View this message in context: > http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-tp2419703p2979519.html > Sent from the baseband-devel mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue May 24 13:35:04 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 24 May 2011 15:35:04 +0200 Subject: hmm, sorry, data cable question In-Reply-To: References: <20110204075031.GH6627@prithivi.gnumonks.org> <1305892707538-2965249.post@n3.nabble.com> <1305902639585-2965845.post@n3.nabble.com> <1306241385807-2979519.post@n3.nabble.com> Message-ID: Hi, > you are not frying your mobile only because you are lucky: your com port > fails to deliver the 12~15v standard to the rs232 and delivers 5v instead > > so the 7805 regulator fails to deliver 5v because it's a linear regulator > with a high drop out (internal voltage loss- it is designed to work at at > least 6 or 7v ) plus the diodes voltage drop and it's delivering 3.4v Yup exactly. > if your connect that cable to a good com port, it will drive the calypso at > 5v and it will fry it. right now is delivering 2.5v on tx, and it seems > that's just enough to drive the calypso serial Actually his cable is delivery the 3.4 V. The 2.5V comes from the calypso because its serial port _is_ 2.5V and not 3.3V. We use 3.3V converters because they are more common and work fine, but it's still overdriving the calypso. > also, did anyone tried attaching a phone to a 5v cable to see if it really > dies? It might not die right away, the ESD diodes will take some of it at first ... but for how long is the question. It also depends on the impedance of the driver, if you have a 1k resistor on the path, it would help I guess. But there is also the issue of the 2.5V from the calypso needs to be detected as 1 by a 5V cable. Cheers, Sylvain From roytiberius at gmail.com Wed May 25 09:41:19 2011 From: roytiberius at gmail.com (Roy) Date: Wed, 25 May 2011 02:41:19 -0700 (PDT) Subject: hmm, sorry, data cable question In-Reply-To: References: <20110204075031.GH6627@prithivi.gnumonks.org> <1305892707538-2965249.post@n3.nabble.com> <1305902639585-2965845.post@n3.nabble.com> <1306241385807-2979519.post@n3.nabble.com> Message-ID: <1306316479656-2983706.post@n3.nabble.com> Ok thank you for your comments I've inserted a zener diode between the ground and Rx pin to reduce the tension. http://baseband-devel.722152.n3.nabble.com/file/n2983706/Motorola_T191_unlock_cable_interface_by_Roy_Rev_A.jpg -- View this message in context: http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-tp2419703p2983706.html Sent from the baseband-devel mailing list archive at Nabble.com. From roytiberius at gmail.com Fri May 27 10:28:41 2011 From: roytiberius at gmail.com (Roy) Date: Fri, 27 May 2011 03:28:41 -0700 (PDT) Subject: hmm, sorry, data cable question In-Reply-To: <1306316479656-2983706.post@n3.nabble.com> References: <20110204075031.GH6627@prithivi.gnumonks.org> <1305892707538-2965249.post@n3.nabble.com> <1305902639585-2965845.post@n3.nabble.com> <1306241385807-2979519.post@n3.nabble.com> <1306316479656-2983706.post@n3.nabble.com> Message-ID: <1306492121921-2992388.post@n3.nabble.com> Just now I tested this interface with a Prolific USB cable and works well -- View this message in context: http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-tp2419703p2992388.html Sent from the baseband-devel mailing list archive at Nabble.com. From labadjala6 at gmail.com Sat May 21 21:13:01 2011 From: labadjala6 at gmail.com (labad jala) Date: Sat, 21 May 2011 23:13:01 +0200 Subject: hmm, sorry, data cable question Message-ID: Hi again techies. Thanks for your advises and schemas. I already bought what was announced and illustrated as a mot t191 cable at a french company but it turned to be a "flash cable" with possibly wrong pinout and voltage. If you look at http://www.cellcorner.com/xshp/unlock-phone-codes/motorola-t190-t191-t193-unlock-data-cable.html, it's looks exactly the same one as I have. Did someone buy this one and used it successfully? I measured 4 volts when putting positive pin of my voltmeter to rx and negative pin on ground of the 2.5mm jack.. As said before, don't want to fry my moto. No cable, no project:( Sorry for my noobie question on this high level mailing list... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste7an at gmail.com Fri May 13 07:15:22 2011 From: ste7an at gmail.com (ste7an) Date: Fri, 13 May 2011 09:15:22 +0200 Subject: about voice In-Reply-To: References: Message-ID: I am trying to convert the voice.raw file generated by the mobile application ion the Sylvain's test branch to audible audio using the GAPK tool. I seem not to be able to run in with the apropriate parameters as I only get screeching sounds as a result. I assume the the raw TI calypso audio is in the format indicated with ti-fr. I tried things as: gapk -i voice.raw -i voice.pcm -f ti-fr -g rawpcm-s16le but with no usefull result. Could anyone give me some guidance? regards, Stefan ----------------------- this is the output of the GAPK tool as I compiled it with the supported codecs. Is there anything missing? Usage: /home/gsm/project/gsm/gapk/src/.libs/lt-gapk [options] Options: -i, --input-file=FILE Input file -o, --output-file=FILE Output file -f, --input-format=FMT Input format (see below) -g, --output-format=FMT Output format (see below) Supported codecs: name fmt enc dec description pcm * Raw PCM signed 16 bits samples hr * * * GSM 06.20 Half Rate codec fr * GSM 06.10 Full Rate codec (classic gsm codec) efr * GSM 06.60 Enhanced Full Rate codec Supported formats: amr-efr Classic .amr file containing EFR (=AMR 12.2k) data gsm Classic .gsm file format hr-ref-dec 3GPP HR Reference decoder code parameters file format hr-ref-enc 3GPP HR Reference encoder code parameters file format racal-hr Racal HR TCH/H recording racal-fr Racal FR TCH/F recording racal-efr Racal EFR TCH/F recording rawpcm-s16le Raw PCM samples Signed 16 bits little endian ti-hr Texas Instrument HR TCH/H buffer format ti-fr Texas Instrument FR TCH/F buffer format ti-efr Texas Instrument EFR TCH/F buffer format -------------- next part -------------- An HTML attachment was scrubbed... URL: From edrocoyote at yahoo.es Tue May 17 03:27:12 2011 From: edrocoyote at yahoo.es (Pedro Collado) Date: Tue, 17 May 2011 05:27:12 +0200 Subject: would be desirable to have a live-cd-bb osmocom References: Message-ID: like openbts From holger at freyther.de Mon May 23 07:06:53 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 23 May 2011 09:06:53 +0200 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: References: Message-ID: <4DDA078D.2080900@freyther.de> On 05/17/2011 05:27 AM, Pedro Collado wrote: > like openbts sure. Would you want to create the scripts for that? holger From lokkju at gmail.com Mon May 23 07:56:38 2011 From: lokkju at gmail.com (Lokkju Brennr) Date: Mon, 23 May 2011 00:56:38 -0700 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: <4DDA078D.2080900@freyther.de> References: <4DDA078D.2080900@freyther.de> Message-ID: If we just create a Debian dpkg that packages all the osmocom functionality, it'd be really easy to pull off with Debian Live. Hell, there is event a web based livecd builder. Of course, the question is which branch, and what options are enabled... I will say it would be nice to have a set of reference binaries (both host and target), so you could immediately rule out any build issues when troubleshooting. I might be interested in building the packaging scripts if no one else is already working on it. Loki On Mon, May 23, 2011 at 12:06 AM, Holger Hans Peter Freyther wrote: > On 05/17/2011 05:27 AM, Pedro Collado wrote: >> like openbts > > sure. Would you want to create the scripts for that? > > holger > > From laforge at gnumonks.org Mon May 23 08:08:06 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 23 May 2011 10:08:06 +0200 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: References: <4DDA078D.2080900@freyther.de> Message-ID: <20110523080806.GA7651@prithivi.gnumonks.org> Hi Lokkju and others, On Mon, May 23, 2011 at 12:56:38AM -0700, Lokkju Brennr wrote: > If we just create a Debian dpkg that packages all the osmocom > functionality, it'd be really easy to pull off with Debian Live. That is not that easy. You will first need to package a cross-toolchain, and then include the source code for at least the OsmocomBB firmware. Also, how to cleanly handle the libosmocore cross-compilation in a debian package is probably not that simple. For OpenBSC, packaging stuff is easy and fine. But OsmocomBB, it is an entirely different story. I think there's no alternative to simply include the git repository and have people compile the specific branches they want, with manual TX enabling, etc. The other issue with distributing a live CD with lots of exceutable code is of course license compliance. This means at least for all GPL/LGPL/AGPL licensed code, the complete corresponding source code has to be offered and made available. > I will say it would be nice to have a set of reference binaries (both > host and target), so you could immediately rule out any build issues > when troubleshooting. I don't think so. Especially for the host, you have so many things that play into the picture (architecture, libraries/versions, host CPU architecture, ...) > I might be interested in building the packaging scripts if no one else > is already working on it. I've recently posted a call for a dpkg package maintainer. This would be a start for libosmocore, openbsc, openggsn, etc. Next steps would be: * package a suitable cross-toolchain * make osmocom-bb host programs use the libosmocore on the host * create a package for the cross-compiled (target) libosmocore * provide an apt repository of all the packages (and source packages) Creating the Live CD is the easiest and last step. Please don't start with the last step before the preconditions are met. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From suraev at stud.ntnu.no Mon May 23 09:55:57 2011 From: suraev at stud.ntnu.no (suraev at stud.ntnu.no) Date: Mon, 23 May 2011 11:55:57 +0200 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: <20110523080806.GA7651@prithivi.gnumonks.org> References: <4DDA078D.2080900@freyther.de> <20110523080806.GA7651@prithivi.gnumonks.org> Message-ID: <4DDA2F2D.3000903@stud.ntnu.no> 23.05.2011 10:08, Harald Welte ?????: > That is not that easy. You will first need to package a > cross-toolchain, and then include the source code for at least the > OsmocomBB firmware. Probably this https://launchpad.net/~bdrung/+archive/bsprak could be a good starting point for toolchain packaging. cheers, Max. From holger at freyther.de Mon May 23 11:54:57 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 23 May 2011 13:54:57 +0200 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: <4DDA2F2D.3000903@stud.ntnu.no> References: <4DDA078D.2080900@freyther.de> <20110523080806.GA7651@prithivi.gnumonks.org> <4DDA2F2D.3000903@stud.ntnu.no> Message-ID: <4DDA4B11.5040201@freyther.de> On 05/23/2011 11:55 AM, suraev at stud.ntnu.no wrote: > 23.05.2011 10:08, Harald Welte ?????: > >> That is not that easy. You will first need to package a >> cross-toolchain, and then include the source code for at least the >> OsmocomBB firmware. > > Probably this https://launchpad.net/~bdrung/+archive/bsprak could be a good starting > point for toolchain packaging. Yes, either abuse the GNU/Linux ARM toolchain from Embedian (or in Ubuntu the Linaro cross gcc), or we need to package a plain ARM ELF newlib one. holger From wolfram at the-dreams.de Mon May 23 12:43:12 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 23 May 2011 14:43:12 +0200 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: <4DDA4B11.5040201@freyther.de> References: <4DDA078D.2080900@freyther.de> <20110523080806.GA7651@prithivi.gnumonks.org> <4DDA2F2D.3000903@stud.ntnu.no> <4DDA4B11.5040201@freyther.de> Message-ID: <4DDA5660.3000000@the-dreams.de> > either abuse the GNU/Linux ARM toolchain from Embedian (or in Ubuntu the > Linaro cross gcc), or we need to package a plain ARM ELF newlib one. There are packages here: ftp://ftp.pengutronix.de/pub/oselas/ DEBs (also tbz2) for i386 and amd64 (arm-elf-gcc-4.5.2-newlib-1.19.0-binutils-2.21). That are the ones I use. Recipes to build them on your own are available[1], but needs ptxdist as a buildsystem, so no debian-mechanisms for that. Regards, Wolfram [1] http://ptxdist.de/oselas/toolchain/download/OSELAS.Toolchain-2011.03.0.tar.bz2 From khorben at defora.org Tue May 24 23:16:49 2011 From: khorben at defora.org (Pierre Pronchery) Date: Wed, 25 May 2011 01:16:49 +0200 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: <20110523080806.GA7651@prithivi.gnumonks.org> References: <4DDA078D.2080900@freyther.de> <20110523080806.GA7651@prithivi.gnumonks.org> Message-ID: <4DDC3C61.1080706@defora.org> Hi all, On 23/05/2011 10:08, Harald Welte wrote: > Hi Lokkju and others, > > On Mon, May 23, 2011 at 12:56:38AM -0700, Lokkju Brennr wrote: >> If we just create a Debian dpkg that packages all the osmocom >> functionality, it'd be really easy to pull off with Debian Live. some packages are available in the hackable:1 project: http://trac.hackable1.org/ http://build.hackable1.org/debian/dists/wip-oldstable/main/ As the last URL suggests, I haven't updated them for a while though :/ > That is not that easy. You will first need to package a > cross-toolchain, and then include the source code for at least the > OsmocomBB firmware. Also, how to cleanly handle the libosmocore > cross-compilation in a debian package is probably not that simple. It is not easy, but feasible. I have used the toolchain from the Emdebian project, and managed to cross-compile libosmocore. The GSM applications compiled this way did not fully work though. It would be really nice if OsmocomBB's code could support more toolchains; I'll try to investigate this myself if I can find some time for this. > For OpenBSC, packaging stuff is easy and fine. But OsmocomBB, it is an > entirely different story. I think there's no alternative to simply > include the git repository and have people compile the specific > branches they want, with manual TX enabling, etc. Right, this is another issue altogether. There also, it would be great if some features could be enabled through command-line arguments, but I also understand why this is not always feasible/desirable even. As for choosing branches, that's going to be the case for pretty much any software package in any distribution, and my preference goes for tracking "stable" code, and therefore track the "master" branch by default. For the record, my packages were using the master branch indeed, with TX disabled IIRC. > The other issue with distributing a live CD with lots of exceutable code > is of course license compliance. This means at least for all > GPL/LGPL/AGPL licensed code, the complete corresponding source code has > to be offered and made available. hackable:1 also features a script to generate ready-to-boot images, and could be extended to generate live CDs. Since it is based on Debian and fully open source, GPL compliance should not be an issue. >> I might be interested in building the packaging scripts if no one else >> is already working on it. > > I've recently posted a call for a dpkg package maintainer. This would > be a start for libosmocore, openbsc, openggsn, etc. TBH, I do not want to be that maintainer; but my work should be easy to grab and maintain. > Next steps would be: > * package a suitable cross-toolchain There is emdebian, but as mentioned, it is (was?) not fully functional on the target side of things. > * make osmocom-bb host programs use the libosmocore on the host Isn't this managed by the code upstream, rather than packaging? > * create a package for the cross-compiled (target) libosmocore Isn't the library automatically included in the final applicative images? (I haven't had a look at the project for a while, sorry) > * provide an apt repository of all the packages (and source packages) hackable:1 can do that too. > Creating the Live CD is the easiest and last step. Please don't start > with the last step before the preconditions are met. :) HTH, -- khorben From holger at freyther.de Mon May 23 08:38:52 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 23 May 2011 10:38:52 +0200 Subject: would be desirable to have a live-cd-bb osmocom In-Reply-To: References: <4DDA078D.2080900@freyther.de> Message-ID: <4DDA1D1C.408@freyther.de> On 05/23/2011 09:56 AM, Lokkju Brennr wrote: > If we just create a Debian dpkg that packages all the osmocom > functionality, it'd be really easy to pull off with Debian Live. > Hell, there is event a web based livecd builder. Of course, the > question is which branch, and what options are enabled... > > I will say it would be nice to have a set of reference binaries (both > host and target), so you could immediately rule out any build issues > when troubleshooting. > > I might be interested in building the packaging scripts if no one else > is already working on it. Everything but osmocom-bb has debian packaging support, I once played with the embedded debian project (an easy way to get a GNU/Linux ARM) toolchain, so it might be quite easy to cross-compile and package. please go ahead. holger From laforge at gnumonks.org Sat May 14 16:46:37 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 14 May 2011 18:46:37 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <4DA9EF82.8040107@l--putt.de> References: <4DA9EF82.8040107@l--putt.de> Message-ID: <20110514164637.GA18422@prithivi.gnumonks.org> Hi all, I'd like to re-vitalize the RTOS discussions. I've now spend some hours reviewing the Nuttx documentation, source code, change logs and other information, and I'm impressed! From 246tnt at gmail.com Sat May 14 20:41:59 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Sat, 14 May 2011 20:41:59 +0000 Subject: RFC: RTOS for Calypso In-Reply-To: <20110514164637.GA18422@prithivi.gnumonks.org> Message-ID: <90e6ba6e8d2c36090f04a3427491@google.com> Hi, > So unless anyone raises major objections, I think we should move ahead > with Nuttx. Who is interested in working on the calypso port? I'd definitely like to be involved in that, especially for the GSM specific part and L1 integration and possibly trying to define more abstract interface for it (so that we can switch from calypso to MTK. The current common code makes calls from common code to calypso specific stuff directly). I'm off until next week but after that I'll definitely look into it. Some things from the top of my head that needs to be taken care of from the get go (to be on solid ground): - Platform (mtk / calypso / qemu?) and board support. Possibly even variant (US / EU versions) - Configuration options (TX enable / debug mode / ... ) - For each type of device (spi / i2c / keyboard / ...), define a clear 'Driver API' that each specific driver - As you said, memory allocator :) (note that some/many of those may be taken care of by nuttx itself) > Meanwhile we will figure out how it would be > possibel to keep the gsm related 'application' code out-of-tree from > the nuttx code base. Any idea how to do that yet ? Essentially the GSM part is three things : - A collection of drivers for the hw part - A FIQ handler (the only one) - A background task that communicates with serial. (altough currently it's all handled in IRQ and that's bad) I'm kind of in favor of progressively recopying all the code we have in a new directory and clean it up as we go. (so we keep the currently working L1 in the current dir and just progressively import functionality). This way we can at each addition take care of what we did wrong the first time around. (And I'd definitely like to be involved in that process). Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfram at the-dreams.de Sun May 15 20:17:28 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sun, 15 May 2011 22:17:28 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <20110514164637.GA18422@prithivi.gnumonks.org> References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> Message-ID: <4DD034D8.3090101@the-dreams.de> > As for where to put the code: I already have a git-svn clone of Nuttx, > and will push that to a soon-to-be-created nuttx.git repository on > git.osmocom.org. The core calypso support (irq, uart, spi, etc.) should > all go in that tree. Meanwhile we will figure out how it would be > possibel to keep the gsm related 'application' code out-of-tree from > the nuttx code base. Nuttx is BSD, osmocom code is GPL. So, shall osmocom code for Nuttx be relicensed and only the application-repro contain GPL-code (probably no problem for drivers, but what about l1-code)? Or are we keeping GPL and keep in sync with upstream on our own (merging could get quite ugly if that diverges too much)? Regards, Wolfram From 246tnt at gmail.com Sun May 15 20:29:03 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 15 May 2011 16:29:03 -0400 Subject: RFC: RTOS for Calypso In-Reply-To: <4DD034D8.3090101@the-dreams.de> References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> <4DD034D8.3090101@the-dreams.de> Message-ID: > Nuttx is BSD, osmocom code is GPL. So, shall osmocom code for Nuttx be > relicensed and only the application-repro contain GPL-code (probably no > problem for drivers, but what about l1-code)? Or are we keeping GPL and keep > in sync with upstream on our own (merging could get quite ugly if that > diverges too much)? I'd keep GPL for everything except custom modification of nuttx code (if even required). There is no problem to have mixed BSD and GPL code in the same repository as long as the header of each file has clear mention. All our drivers (even for board / platforms / ...) will be new files and all of L1 as well. Keeping in sync with upstream shouldn't be that hard if done periodically. I also assume they don't rewrite their whole API every month ... Cheers, Sylvain From laforge at gnumonks.org Mon May 16 05:19:13 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 16 May 2011 07:19:13 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <4DD034D8.3090101@the-dreams.de> References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> <4DD034D8.3090101@the-dreams.de> Message-ID: <20110516051913.GA24739@prithivi.gnumonks.org> Hi Wolfram, On Sun, May 15, 2011 at 10:17:28PM +0200, Wolfram Sang wrote: > Nuttx is BSD, osmocom code is GPL. So, shall osmocom code for Nuttx > be relicensed and only the application-repro contain GPL-code I think all the calypso driver code to get the Soc supported in NuttX (spi/lcd/i2c/uart/flash/sercomm/...) should eventually go Nuttx upstream and I have no problem re-licensing that under the BSD-style license. > (probably no problem for drivers, but what about l1-code)? Or are we > keeping GPL and keep in sync with upstream on our own (merging could > get quite ugly if that diverges too much)? I think the L1 would be two parts: the synchronous part in the FIQ, and one 'userspace' task (might have multiple threads) for everything else. Both should be fine as GPL, and I don't expect major headaches with keeping it in sync. The FIQ handler is completely independent from the RTOS and pre-empts it anywhere. If Nuttx right now is blocking FIQs, we should propose to change that in upstream, but still keep the L1S in our tree. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sweisman at pobox.com Mon May 16 16:27:20 2011 From: sweisman at pobox.com (Scott Weisman) Date: Mon, 16 May 2011 19:27:20 +0300 Subject: RFC: RTOS for Calypso In-Reply-To: <20110516051913.GA24739@prithivi.gnumonks.org> References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> <4DD034D8.3090101@the-dreams.de> <20110516051913.GA24739@prithivi.gnumonks.org> Message-ID: I mentioned RT-Thread in the last email I sent to this thread. I don't know if anyone looked into it, but it has some intriguing features that I think are also worthy of consideration. It looks to be actively developed and is licensed under the Apache Licence 2.0. Here's a summary from their site ( http://code.google.com/p/rt-thread/). The GUI mentioned below is nothing to write home about, but it has TTF support, among other things. That particular feature might seem heavy, but it is nice to know it's available. Scott RT-Thread Kernel Object oriented real-time core (while remaining the elegant and flexible style of C Programming Language); 32 or 256 priority scheduling multi-thread scheduling; Using the round-robin policy ensures that all threads having the same priority level will be scheduled equally; Synchronization of threads: semaphore and mutual exclusion semaphore (mutex) to prevent priority inversion; Complete and efficient support for communication between threads, including mailbox, message queues, event flag; Static memory management supports thread suspend/resume when it allocates/frees a memory block and thread-safe dynamic heap management; A device driver framework to provide standard interface to high level application; FinSH shell Command line that accepts C-like expression; Access system core functions directly via command line like C Programming Language grammar; Access system global variables directly via command line like C Programming Language grammar; Command history records and automatic complete for the Command Prompt; Device File System Virtual File System optimised for small device POSIX style API; Support the different implementation of file systems Wrapper for ELM Chan's FatFs filesystem. LwIP, a lightweight TCP/IP protocol stack Standard BSD Socket interface; IP, ICMP, UDP, TCP supported DNS, DHCP, PPP supported TFTP-HTTP-FTP supported (refer to the netutil component) RT-Thread/GUI Integrated with RT-Thread; Multi-Thread supported; Multi-Window supported; Rich Widgets such as: label, button, checkbox, radiobox, etc. Client/Server Architecture; Client: Workbench/View/Window Architecture; Chinese GB2312 display. RT-Thread Branches 0.3.x STM32 LM3S ATMEL 7X256 LPC2478 x86 RT-Thread Branches 0.4.x mini2440 AVR32 Renesas M16C Cortex-M0 (NXP lpc1114) RT-Thread 0.4.x branches has been starting in Google SVN trunk. It will include more microcontrollers porting and involve following features: Enhanced features on RT-Thread/GUI, include framebuffer optimized, input method, TrueType font, Alpha Blend etc. Application Module. Other features. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Mon May 16 16:33:51 2011 From: peter at stuge.se (Peter Stuge) Date: Mon, 16 May 2011 18:33:51 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> <4DD034D8.3090101@the-dreams.de> <20110516051913.GA24739@prithivi.gnumonks.org> Message-ID: <20110516163352.27896.qmail@stuge.se> Scott Weisman wrote: > TTF support See also http://nothings.org/stb/stb_truetype.h Some fonts are rendered really beautifully, others not so much, others still not at all. It doesn't do bells and whistles kerning but hey, it's a 67kb public domain TTF renderer! //Peter From drasko.draskovic at gmail.com Mon May 16 09:14:06 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 16 May 2011 11:14:06 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <20110514164637.GA18422@prithivi.gnumonks.org> References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> Message-ID: On Sat, May 14, 2011 at 6:46 PM, Harald Welte wrote: > Hi all, > > I'd like to re-vitalize the RTOS discussions. > > I've now spend some hours reviewing the Nuttx documentation, source > code, change logs and other information, and I'm impressed! > > From all that I've seen, it really seems like a good fit. > * it tries to stay as close to POSIX and other Unix APIs as possible > * you can actually have executable programs in the file system > * it contains a small interactive shell > * the changelog is verbose and releases are frequent > * there's a test suite > * there are already ports to other ARM7TDMI microcontrollers > * there is a small UI framework and the notion of drivers for SPI- > ?attached LCDs (with 1/2/4 bpp) > * it has tasks and threads, pre-emptive and with priorities > * it has posix message queues, which we could use for passing around > ?primitives between elements in the stack > * it can be used on Unix-like and Windows/Cygwin host OS > * it has its own scripts to generate toolchains, which means we > ?could possibly standardize on one of those toolchains Hi Harald, as I mentioned before, I think that Nuttx is an excellent choice. > > Of course, not everything is perfect > * there seems to be no writeable FS we can put in NOR flash > * it has no scripting language integration (like lua) yet Which RTOS that can fit in ARM7TDMI mem does ? I can see that eLua has ARM7TDMI support (http://www.eluaproject.net/en_status.html), but I am not sure what are the memory requirements... > * i didn't find any memory allocator optimized for pools of objects > ?of the same size (like 'struct msgb' or the like). ?Something with > ?an API [not implementation!] of the SLAB/SLUB in Linux would probably > ?be a good start. > > I've done some example compile runs for arm7, including the shell and > the graphics support (nx example). I end up with an object code size of > something like 70 kilobytes, which is pretty good! This is really good. > So unless anyone raises major objections, I think we should move ahead > with Nuttx. ?Who is interested in working on the calypso port? I am very interested in taking a roll in this. While pure protocol stack is not my biggest passion, RTOS and device drivers (platform stuff in general) is something I really like to work on. > > Let's use this list for coordinating the effort. > > As for where to put the code: I already have a git-svn clone of Nuttx, > and will push that to a soon-to-be-created nuttx.git repository on > git.osmocom.org. ?The core calypso support (irq, uart, spi, etc.) should > all go in that tree. ?Meanwhile we will figure out how it would be > possibel to keep the gsm related 'application' code out-of-tree from > the nuttx code base. As soon as you push the code I will take a look at it. Should we make some list of priorities / roadmap ? I think that dividing the work in the set of tasks that go bottom-up, from the HAL to shell and apps, would be better for organization. Best regards, Drasko From ichgeh at l--putt.de Mon May 16 11:08:51 2011 From: ichgeh at l--putt.de (l--putt) Date: Mon, 16 May 2011 13:08:51 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <20110514164637.GA18422@prithivi.gnumonks.org> References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> Message-ID: <4DD105C3.2050303@l--putt.de> On 14.05.2011 18:46, Harald Welte wrote: > Hi all, > > I'd like to re-vitalize the RTOS discussions. > > I've now spend some hours reviewing the Nuttx documentation, source > code, change logs and other information, and I'm impressed! > I would argue that this might be the biggest drawback of Nuttx. Documentation and source comments are quite coarse. This might be fine if you have basically a single developer who knows the stuff by heart. I don't like to rely on guesses for the parameters of RTOS calls. For example, "context" of irq_dispatch seems to be the saved user space context. It also seems to be ignored anyway but who knows!? Doxygen documentation of NutOS etc. at the other extreme might be excessive. Thus, maybe not a major problem. >> From all that I've seen, it really seems like a good fit. > * it tries to stay as close to POSIX and other Unix APIs as possible > * you can actually have executable programs in the file system > * it contains a small interactive shell > * the changelog is verbose and releases are frequent > * there's a test suite > * there are already ports to other ARM7TDMI microcontrollers Indeed. The TI C5471 DSP/ARM chip seems to be virtually a predecessor of the Calypso. > * there is a small UI framework and the notion of drivers for SPI- > attached LCDs (with 1/2/4 bpp) > * it has tasks and threads, pre-emptive and with priorities > * it has posix message queues, which we could use for passing around > primitives between elements in the stack > * it can be used on Unix-like and Windows/Cygwin host OS > * it has its own scripts to generate toolchains, which means we > could possibly standardize on one of those toolchains > > Of course, not everything is perfect > * there seems to be no writeable FS we can put in NOR flash There is nxffs but with its limitations you are probably right... > * it has no scripting language integration (like lua) yet > * i didn't find any memory allocator optimized for pools of objects > of the same size (like 'struct msgb' or the like). Something with > an API [not implementation!] of the SLAB/SLUB in Linux would probably > be a good start. > > I've done some example compile runs for arm7, including the shell and > the graphics support (nx example). I end up with an object code size of > something like 70 kilobytes, which is pretty good! > > So unless anyone raises major objections, I think we should move ahead > with Nuttx. Who is interested in working on the calypso port? > I'm already working on the IRQ subsystem and took a look at the UART. But there are open questions, see above... > Let's use this list for coordinating the effort. > > As for where to put the code: I already have a git-svn clone of Nuttx, > and will push that to a soon-to-be-created nuttx.git repository on > git.osmocom.org. The core calypso support (irq, uart, spi, etc.) should > all go in that tree. Meanwhile we will figure out how it would be > possibel to keep the gsm related 'application' code out-of-tree from > the nuttx code base. > > Regards, > Harald From acassis at gmail.com Mon May 16 12:23:25 2011 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Mon, 16 May 2011 09:23:25 -0300 Subject: Fwd: Fwd: RFC: RTOS for Calypso In-Reply-To: <486826.97674.qm@web31805.mail.mud.yahoo.com> References: <4DA9EF82.8040107@l--putt.de> <20110514164637.GA18422@prithivi.gnumonks.org> <407825.29519.qm@web31813.mail.mud.yahoo.com> <486826.97674.qm@web31805.mail.mud.yahoo.com> Message-ID: FYI ---------- Forwarded message ---------- From: Gregory Nutt Date: Sun, 15 May 2011 07:52:18 -0700 (PDT) Subject: Re: Fwd: RFC: RTOS for Calypso To: Alan Carvalho de Assis Hi Alan, I also notice that they are using a TI dual core, ARM7TDMI and C5 DSP. I already have support for a TI chip like that (the C5471) and also for an ARM9 with C5 DSP (DM320). See http://focus.ti.com.cn/cn/lit/ml/sprt239/sprt239.pdf I have a c5 DSP bridge driver somewhere around on my backup disks as well. I never released it into NuttX because there was never any need. Perhaps that could be useful now. Somewhere I also have tools that will convert the TI proprietary object files and logic to manage loading different programs into the DSP. The bridge also supports communication channels to communicate with the DSP. Greg From suraev at stud.ntnu.no Sun May 15 23:18:26 2011 From: suraev at stud.ntnu.no (suraev at stud.ntnu.no) Date: Mon, 16 May 2011 01:18:26 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <4DA9EF82.8040107@l--putt.de> References: <4DA9EF82.8040107@l--putt.de> Message-ID: <4DD05F42.5070900@stud.ntnu.no> Hi. This was probably discussed before so links to rtfms are appreciated, Am I right that some rtos is required only if the device has just baseband processor? In case of openmoko we can implement support for L1CTL in FSO framework and use any existing Linux running on application processor? cheers, Max. From laforge at gnumonks.org Mon May 16 05:22:33 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 16 May 2011 07:22:33 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <4DD05F42.5070900@stud.ntnu.no> References: <4DA9EF82.8040107@l--putt.de> <4DD05F42.5070900@stud.ntnu.no> Message-ID: <20110516052233.GB24739@prithivi.gnumonks.org> Hi! On Mon, May 16, 2011 at 01:18:26AM +0200, suraev at stud.ntnu.no wrote: > Am I right that some rtos is required only if the device has just > baseband processor? well, RTOS is mostly required for running other tasks aside from L1 such as L2, L3, MMI (UI), etc. > In case of openmoko we can implement support for L1CTL in FSO > framework and use any existing Linux running on application processor? Of course you can do that. But I think after the RTOS port of OsmocomBB is completed, not many people will still try to maintain the old pre-RTOS code. But at least in one version of the new proposed RTOS based firmware, we would expose the same L1CTL interface via SERCOMM on the UART, so you could still run the same layer23/mobile stuff on the host PC (or Openmoko Application Processor). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spudarnia at yahoo.com Mon May 16 21:21:45 2011 From: spudarnia at yahoo.com (Gregory Nutt) Date: Mon, 16 May 2011 14:21:45 -0700 (PDT) Subject: RFC: RTOS for Calypso In-Reply-To: References: Message-ID: <49835.57356.qm@web31810.mail.mud.yahoo.com> Hi, List, I heard through the grape vine that you are considering using NuttX. ?I don't want to influence your decision, but if the decision is final, I would like to offer any support to the project that I can give. > Indeed. The TI C5471 DSP/ARM chip seems to be virtually a predecessor of the Calypso. I have quite a bit of experience working with these TI dual core chips and would be happy to help out as much as possible. ?With the ARM7/c5 family, I have developed OS support (uClinux) for the C5471, DSC21, DSC24, and DM270. ?Also the DM320 (ARM9/c5, Linux). I founded this business in Costa Rica (http://www.ridgerun.com, also once called Cadenux). ?But have not been involved with the more recent ARM11/Cortex A8/c6 chips. > I'm already working on the IRQ subsystem and took a look at the UART.? > But there are open questions, see above... There is a porting guide here may be helpful to you: http://nuttx.sourceforge.net/NuttxPortingGuide.html. But it does a some "To be provided" sections -- particulary in the IRQ section. > I have a c5 DSP bridge driver somewhere around on my backup disks as > well. ?I never released it into NuttX because there was never any > need. ?Perhaps that could be useful now. These DSP bridge drivers present interfaces to load programs into the DSP and to support an integrated, seamless messaging system between the ARM7 and the DSP. The DSP interfaces differ from chip to chip and the drivers that I was referring were targeted for uClinux. ?However, if that is something you are interested in, I would be happy to do the port a driver and integrate DSP messaging with the NuttX messaging. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu May 19 07:36:38 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 19 May 2011 09:36:38 +0200 Subject: RFC: RTOS for Calypso In-Reply-To: <49835.57356.qm@web31810.mail.mud.yahoo.com> References: <49835.57356.qm@web31810.mail.mud.yahoo.com> Message-ID: <20110519073638.GG2974@prithivi.gnumonks.org> Hi Gregory, On Mon, May 16, 2011 at 02:21:45PM -0700, Gregory Nutt wrote: > I heard through the grape vine that you are considering using NuttX. > ?I don't want to influence your decision, but if the decision is > final, I would like to offer any support to the project that I can > give. thanks a lot for your feedback and assistance, it is very much appreciated. > > I have a c5 DSP bridge driver somewhere around on my backup disks as > > well. ?I never released it into NuttX because there was never any > > need. ?Perhaps that could be useful now. > > These DSP bridge drivers present interfaces to load programs into the > DSP and to support an integrated, seamless messaging system between > the ARM7 and the DSP. > > The DSP interfaces differ from chip to chip and the drivers that I was > referring were targeted for uClinux. ?However, if that is something > you are interested in, I would be happy to do the port a driver and > integrate DSP messaging with the NuttX messaging. The DSP/ARM interface on the Ti Calyspo is very much defined by the mask rom code in the DSP. I think it is extremely GSM specific, and we already have full support for it in our existing osmocom-bb code... so I don't think we would be able to base this on anything existing. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dario.lombardo at libero.it Thu May 19 08:31:35 2011 From: dario.lombardo at libero.it (Dario Lombardo) Date: Thu, 19 May 2011 10:31:35 +0200 Subject: Nokia 3310 tracing In-Reply-To: References: Message-ID: <4DD4D567.7030406@libero.it> Hi Duncan Today I've received my brand new fbus cable. I've tried it with an old 3310 and your software works perfectly. I think I will test it a lot because nokia 3310s are very common here in italy. I will keep you update with my impressions and so on. Other than the links in your code, is there some official documentation about the fbus protocol? Dario. On 04/25/2011 12:17 PM, Duncan Salerno wrote: > Hi, > > I've put together a small program that puts Nokia 3310 phones into > debug mode (via serial/USB cable) and forwards all sent/received GSM > messages and SIM APDUs via GSMTAP to be viewed realtime in Wireshark. > This allows you to see the message flows for a real phone on a real > network. > > Nokia 3310's are very cheap and easy to come by, so should appeal to a > wide audience. > > Thought osmocom might be a good home for this utility - could it go > into git, and a short page on bb.osmocom.org? > > Duncan From duncan.salerno at googlemail.com Sat May 28 08:32:43 2011 From: duncan.salerno at googlemail.com (Duncan Salerno) Date: Sat, 28 May 2011 09:32:43 +0100 Subject: Nokia 3310 tracing In-Reply-To: <4DD4D567.7030406@libero.it> References: <4DD4D567.7030406@libero.it> Message-ID: Hi Dario, Glad its working well for you! Don't know of any official FBUS documentation, the best places to look are the gammu source and google unfortunately. Duncan On Thu, May 19, 2011 at 9:31 AM, Dario Lombardo wrote: > Hi Duncan > Today I've received my brand new fbus cable. I've tried it with an old 3310 > and your software works perfectly. I think I will test it a lot because > nokia 3310s are very common here in italy. I will keep you update with my > impressions and so on. > Other than the links in your code, is there some official documentation > about the fbus protocol? > > Dario. > > On 04/25/2011 12:17 PM, Duncan Salerno wrote: >> >> Hi, >> >> I've put together a small program that puts Nokia 3310 phones into >> debug mode (via serial/USB cable) and forwards all sent/received GSM >> messages and SIM APDUs via GSMTAP to be viewed realtime in Wireshark. >> This allows you to see the message flows for a real phone on a real >> network. >> >> Nokia 3310's are very cheap and easy to come by, so should appeal to a >> wide audience. >> >> Thought osmocom might be a good home for this utility - could it go >> into git, and a short page on bb.osmocom.org? >> >> Duncan > -- Duncan From wolfram at the-dreams.de Sun May 1 08:18:04 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sun, 01 May 2011 10:18:04 +0200 Subject: [PATCH 1/2] comm: msgb: don't set backlight on error In-Reply-To: References: <1304150031-28644-1-git-send-email-wolfram@the-dreams.de> <1304150031-28644-2-git-send-email-wolfram@the-dreams.de> Message-ID: <4DBD173C.2030208@the-dreams.de> On 30/04/11 10:12, Sylvain Munaut wrote: > Hi, > > On Sat, Apr 30, 2011 at 9:53 AM, Wolfram Sang wrote: >> It seems just to be a debugging aid, but brings in an unwanted >> calypso-dependency. > > > Well it is :) > > I suggest you just replace it by a 'board_panic' call or something and > leave it to the board specific code how to signal panic conditions. I had another look and still have the impression that backlight usage should just go. Look at the implementation when the file was introduced: +panic: + while (1) { + bl_level(++i % 50); + delay_ms(50); + } + return NULL; This, I understand, it blinks. But it was changed three days later to the current state (c917fd43797c30385a1ba860fef95be97c84d51d) which broke it ('i' is constant now). So it is broken for over a year and nobody noticed :) So, instead of introducing a board_panic which nobody seems to need, I'd just suggest using plain osmo_panic as in other places. Much cleaner, too, IMO. Regards, Wolfram From wolfram at the-dreams.de Sun May 1 08:36:09 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sun, 01 May 2011 10:36:09 +0200 Subject: [PATCH 1/2] comm: msgb: don't set backlight on error In-Reply-To: <4DBD173C.2030208@the-dreams.de> References: <1304150031-28644-1-git-send-email-wolfram@the-dreams.de> <1304150031-28644-2-git-send-email-wolfram@the-dreams.de> <4DBD173C.2030208@the-dreams.de> Message-ID: <4DBD1B79.4060401@the-dreams.de> > noticed :) So, instead of introducing a board_panic which nobody seems > to need, I'd just suggest using plain osmo_panic as in other places. > Much cleaner, too, IMO. Ehrm, considering the while(1)-loop in the current form, this isn't even a panic? So just print the msg as is now? Confused... From laforge at gnumonks.org Mon May 2 07:15:26 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 2 May 2011 09:15:26 +0200 Subject: [PATCH 1/2] comm: msgb: don't set backlight on error In-Reply-To: <4DBD173C.2030208@the-dreams.de> References: <1304150031-28644-1-git-send-email-wolfram@the-dreams.de> <1304150031-28644-2-git-send-email-wolfram@the-dreams.de> <4DBD173C.2030208@the-dreams.de> Message-ID: <20110502071526.GE3301@prithivi.gnumonks.org> Hi Wolfgang, On Sun, May 01, 2011 at 10:18:04AM +0200, Wolfram Sang wrote: > This, I understand, it blinks. But it was changed three days later > to the current state (c917fd43797c30385a1ba860fef95be97c84d51d) > which broke it ('i' is constant now). So it is broken for over a > year and nobody noticed :) Well, let's say we noticed that we get layer1 panics without any indication. > So, instead of introducing a board_panic which nobody seems to need, I'd just > suggest using plain osmo_panic as in other places. Much cleaner, too, IMO. I disagree. We desperately need board_panic, (with much more than just backlight blinking in the future), to be able to solve the various mysterious layer1/firmware crashes that we're seeing more or less all the time. I had recently discussed this with Andreas and Sylvain at the Easterhegg, and they both agreed that we need a way to debug crashes better. We need to tap into the various exception handlers, we need to use the debug unit to get backtraces, and we need ways like backlight blinking or buzzer sounds that can be done from a few lines of stack-independent assembly code to reliably indicate what has happened to the system. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Mon May 2 12:02:23 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 2 May 2011 14:02:23 +0200 Subject: [PATCH 1/2] comm: msgb: don't set backlight on error In-Reply-To: <20110502071526.GE3301@prithivi.gnumonks.org> References: <1304150031-28644-1-git-send-email-wolfram@the-dreams.de> <1304150031-28644-2-git-send-email-wolfram@the-dreams.de> <4DBD173C.2030208@the-dreams.de> <20110502071526.GE3301@prithivi.gnumonks.org> Message-ID: Hi, > I disagree. ?We desperately need board_panic, (with much more than just > backlight blinking in the future), to be able to solve the various mysterious > layer1/firmware crashes that we're seeing more or less all the time. Yes, it definitely needed. And calling osmo_panic might be the right thing, and then have the board register their osmo_panic handler in its init (the buzzer would be a good choice :) (libosmocore already has a way to register a panic handler IIRC which is for the target a while(1) loop by default) Cheers, Sylvain From wolfram at the-dreams.de Mon May 2 12:27:03 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 02 May 2011 14:27:03 +0200 Subject: [PATCH 1/2] comm: msgb: don't set backlight on error In-Reply-To: References: <1304150031-28644-1-git-send-email-wolfram@the-dreams.de> <1304150031-28644-2-git-send-email-wolfram@the-dreams.de> <4DBD173C.2030208@the-dreams.de> <20110502071526.GE3301@prithivi.gnumonks.org> Message-ID: <4DBEA317.7050500@the-dreams.de> On 02/05/11 14:02, Sylvain Munaut wrote: >> I disagree. We desperately need board_panic, (with much more than just >> backlight blinking in the future), to be able to solve the various mysterious >> layer1/firmware crashes that we're seeing more or less all the time. > > Yes, it definitely needed. > > And calling osmo_panic might be the right thing, and then have the > board register their osmo_panic handler in its init (the buzzer would > be a good choice :) Okay, understood that it is needed. Still, the discussion also showed that I seem to not have the proper knowledge of what is desired instead by those people hacking at layer 1 (what I don't do) :) Thus, may I suggest that I just remove the (static value) backlight setting in msgb.c to remove the calypso-dependency and leave a proper board_panic for someone else with a seperate patchset? To me, Harald's post indicates that it is a seperate topic? Regards, Wolfram From laforge at gnumonks.org Mon May 2 20:57:45 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 2 May 2011 22:57:45 +0200 Subject: [PATCH 1/2] comm: msgb: don't set backlight on error In-Reply-To: <4DBEA317.7050500@the-dreams.de> References: <1304150031-28644-1-git-send-email-wolfram@the-dreams.de> <1304150031-28644-2-git-send-email-wolfram@the-dreams.de> <4DBD173C.2030208@the-dreams.de> <20110502071526.GE3301@prithivi.gnumonks.org> <4DBEA317.7050500@the-dreams.de> Message-ID: <20110502205745.GD3477@prithivi.gnumonks.org> On Mon, May 02, 2011 at 02:27:03PM +0200, Wolfram Sang wrote: > Okay, understood that it is needed. Still, the discussion also showed that > I seem to not have the proper knowledge of what is desired instead by > those people hacking at layer 1 (what I don't do) :) Thus, may I suggest > that I just remove the (static value) backlight setting in msgb.c to > remove the calypso-dependency and leave a proper board_panic for someone > else with a seperate patchset? To me, Harald's post indicates that it is a > seperate topic? ACK. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From wolfram at the-dreams.de Sun May 1 19:08:53 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sun, 1 May 2011 21:08:53 +0200 Subject: [PATCH] linuxlist.h: silence a noisy warning Message-ID: <1304276933-13636-1-git-send-email-wolfram@the-dreams.de> Fixes a couple of warnings like this: In file included from ../../shared/libosmocore/include/osmocom/core/msgb.h:24:0, from include/comm/sercomm.h:6, from apps/loader/main.c:41: ../../shared/libosmocore/include/osmocom/core/linuxlist.h: In function 'prefetch': ../../shared/libosmocore/include/osmocom/core/linuxlist.h:10:41: warning: unused parameter 'x' Signed-off-by: Wolfram Sang --- .../libosmocore/include/osmocom/core/linuxlist.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/shared/libosmocore/include/osmocom/core/linuxlist.h b/src/shared/libosmocore/include/osmocom/core/linuxlist.h index fb99c5e..ff2c491 100644 --- a/src/shared/libosmocore/include/osmocom/core/linuxlist.h +++ b/src/shared/libosmocore/include/osmocom/core/linuxlist.h @@ -7,7 +7,7 @@ #define inline __inline__ #endif -static inline void prefetch(const void *x) {;} +static inline void prefetch(__attribute__((unused)) const void *x) {;} /** * container_of - cast a member of a structure out to the containing structure -- 1.7.2.5 From laforge at gnumonks.org Mon May 2 07:11:46 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 2 May 2011 09:11:46 +0200 Subject: [PATCH] linuxlist.h: silence a noisy warning In-Reply-To: <1304276933-13636-1-git-send-email-wolfram@the-dreams.de> References: <1304276933-13636-1-git-send-email-wolfram@the-dreams.de> Message-ID: <20110502071146.GD3301@prithivi.gnumonks.org> On Sun, May 01, 2011 at 09:08:53PM +0200, Wolfram Sang wrote: > Fixes a couple of warnings like this: thanks, applied! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From wbg_1000 at yahoo.com Mon May 2 10:17:57 2011 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Mon, 2 May 2011 03:17:57 -0700 (PDT) Subject: mobile - making a call Message-ID: <558647.10314.qm@web112114.mail.gq1.yahoo.com> Hi. I'm using mobile application (sylvain/testing branch) to initiate calls. My experience is that the call si succesfull in about 20% of cases. Most of the time the connection seems to be lost after receiving the AUTHENTICATION REQUEST message. Has anyone else had this experience, it has to do with the power measurements above? Thanks, Mihai. <0005> gsm48_cc.c:496 Sending MMCC_EST_REQ <0004> gsm48_mm.c:3568 (ms 1) Received 'MMCC_EST_REQ' event in state MM idle <0004> gsm48_mm.c:3571 -> substate normal service <0004> gsm48_mm.c:3573 -> callref 1, transaction_id 255 <0004> gsm48_mm.c:2873 Init MM Connection. <0004> gsm48_mm.c:1332 New MM Connection (proto 0x03 trans_id 255 ref 1) <0004> gsm48_mm.c:1291 (ref 1) new state IDLE -> CONN_PEND <0004> gsm48_mm.c:2650 CM SERVICE REQUEST (cause 9) <0004> gsm48_mm.c:2681 -> Using TMSI <0001> gsm48_rr.c:4904 (ms 1) Message 'RR_EST_REQ' received in state idle <000d> gsm48_rr.c:1181 Establish radio link due to mobility management request <0003> gsm322.c:3319 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:2959 Going to camping frequency 47. <0003> gsm322.c:252 Sync to ARFCN=47 rxlev=-61 (Sysinfo, ccch mode NON-COMB) <0001> gsm48_rr.c:363 new state idle -> connection pending <0001> gsm48_rr.c:1313 CHANNEL REQUEST: e0 (Orig TCH/F) <0004> gsm48_mm.c:887 new state MM IDLE, normal service -> wait for RR connection (MM connection) <0003> gsm322.c:2434 Channel synched. (ARFCN=47, snr=16, BSIC=33) <0001> gsm322.c:2461 using DSC of 90 <0003> gsm48_rr.c:4541 Channel provides data. <0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 5) <0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 0 ra 0xed) <0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 4) <0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 217 ra 0xed) <0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) <0001> gsm48_rr.c:2258 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2270? (ta 1/553m ra 0xed chan_nr 0x41 MAIO 2 HSN 36 TS 1 SS 0 TSC 1) <0001> gsm48_rr.c:2204 request ed matches (fn=4,24,16) <0001> gsm48_rr.c:2304 resetting scheduler <0001> gsm48_rr.c:2858 decoding mobile allocation <0001> sysinfo.c:396 Serving cell ARFCN #0: 31 <0001> sysinfo.c:396 Serving cell ARFCN #1: 44 <0001> sysinfo.c:396 Serving cell ARFCN #2: 47 <0001> sysinfo.c:396 Serving cell ARFCN #3: 57 <0001> sysinfo.c:410 Hopping ARFCN: 0 (bit 31) <0001> sysinfo.c:410 Hopping ARFCN: 1 (bit 44) <0001> sysinfo.c:410 Hopping ARFCN: 2 (bit 47) <0001> sysinfo.c:410 Hopping ARFCN: 3 (bit 57) <0001> gsm48_rr.c:3019 sending establish message <0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) <0001> gsm48_rr.c:2763 setting indicated TA 1 (actual TA 1) <0001> gsm48_rr.c:2774 using last SACCH timeout 16 <0001> gsm48_rr.c:774 stopping pending timer T_meas <0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=1 meas-invalid=1 rxlev-full=-110 rxlev-sub=-110 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:2796 establishing channel in dedicated mode <0001> gsm48_rr.c:2800? Channel type 64, subch 0, ts 1, mode 0, cipher 1 <0001> gsm48_rr.c:363 new state connection pending -> dedicated <0004> gsm48_mm.c:3695 (ms 1) Received 'RR_EST_CNF' from RR in state wait for RR connection (MM connection) <0004> gsm48_mm.c:431 starting T3230 (MM connection timeout) with 15.0 seconds <0004> gsm48_mm.c:897 new state wait for RR connection (MM connection) -> wait for outgoing MM connection <0001> gsm48_rr.c:4488 Indicated ta 1 (actual ta 1) <0001> gsm48_rr.c:4490 Indicated tx_power 5 <0001> gsm48_rr.c:1828 New SYSTEM INFORMATION 5 <0001> gsm48_rr.c:1583 Complete set of SI5* for BA(0) <0001> gsm48_rr.c:1593 SI5* report arfcn 1 <0001> gsm48_rr.c:1593 SI5* report arfcn 3 <0001> gsm48_rr.c:1593 SI5* report arfcn 6 <0001> gsm48_rr.c:1593 SI5* report arfcn 13 <0001> gsm48_rr.c:1593 SI5* report arfcn 17 <0001> gsm48_rr.c:1593 SI5* report arfcn 19 <0001> gsm48_rr.c:1593 SI5* report arfcn 20 <0001> gsm48_rr.c:1593 SI5* report arfcn 21 <0001> gsm48_rr.c:1593 SI5* report arfcn 24 <0001> gsm48_rr.c:1593 SI5* report arfcn 26 <0001> gsm48_rr.c:1593 SI5* report arfcn 30 <0001> gsm48_rr.c:1593 SI5* report arfcn 33 <0001> gsm48_rr.c:1593 SI5* report arfcn 36 <0001> gsm48_rr.c:1593 SI5* report arfcn 37 <0001> gsm48_rr.c:1593 SI5* report arfcn 40 <0001> gsm48_rr.c:1593 SI5* report arfcn 41 <0001> gsm48_rr.c:1593 SI5* report arfcn 42 <0001> gsm48_rr.c:1593 SI5* report arfcn 47 <0001> gsm48_rr.c:1593 SI5* report arfcn 49 <0001> gsm48_rr.c:1593 SI5* report arfcn 58 <0001> gsm48_rr.c:1593 SI5* report arfcn 59 <0004> gsm48_mm.c:4083 (ms 1) Received 'MM_EVENT_SYSINFO' event in state wait for outgoing MM connection <0003> gsm322.c:2104 Sysinfo of selected cell is updated. <0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection <0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection <0004> gsm48_mm.c:468 stopping pending (periodic loc. upd. delay) timer T3212 <0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) <0004> subscriber.c:898 Generating KEY at SIM <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 5 <0001> gsm48_rr.c:4493 setting new ta and tx_power <0001> gsm48_rr.c:609 MON: f=47 lev=-60 snr=11 ber= 27 LAI=226 01 2b96 ID=e328 TA=0 pwr=5 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=0 meas-invalid=0 rxlev-full=-60 rxlev-sub=-60 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 5 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 6 <0001> gsm48_rr.c:4493 setting new ta and tx_power <0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 17 LAI=226 01 2b96 ID=e328 TA=0 pwr=6 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=6 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 7 <0001> gsm48_rr.c:4493 setting new ta and tx_power <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 7 <0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber=? 0 LAI=226 01 2b96 ID=e328 TA=0 pwr=7 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=7 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 8 <0001> gsm48_rr.c:4493 setting new ta and tx_power <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 8 <0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 18 LAI=226 01 2b96 ID=e328 TA=0 pwr=8 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=8 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 8 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 9 <0001> gsm48_rr.c:4493 setting new ta and tx_power <0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 49 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 9 <0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection <0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection <0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) <0004> subscriber.c:898 Generating KEY at SIM <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 9 <0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 32 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 10 <0001> gsm48_rr.c:4493 setting new ta and tx_power <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 10 <0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 41 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 10 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 10 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 10 <0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 74 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 11 <0001> gsm48_rr.c:4493 setting new ta and tx_power <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 11 <0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber=? 9 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 11 <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 11 <0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 35 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 <0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 <0001> gsm48_rr.c:3174 channel release request with cause 0x00) <0001> gsm48_rr.c:363 new state dedicated -> release pending <0001> gsm48_rr.c:738 starting T3110 with 1.500 seconds <000d> gsm48_rr.c:4666 Requested channel aborted <0001> gsm48_rr.c:798 stopping pending timer T3110 <0001> gsm48_rr.c:363 new state release pending -> idle <0003> gsm322.c:3319 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection in state 'C3 camped normally' <0003> gsm322.c:541 new state 'C3 camped normally' -> 'C5 choose cell' <0003> gsm322.c:2820 No BA range(s), try sysinfo. <0003> gsm322.c:2859 free sysinfo arfcn=47 <0003> gsm322.c:2859 free sysinfo arfcn=66 <0004> gsm48_mm.c:3695 (ms 1) Received 'RR_REL_IND' from RR in state wait for outgoing MM connection <0004> gsm48_mm.c:495 stopping pending (MM connection timeout) timer T3230 <0004> gsm48_mm.c:1367 Release any MM Connection <0004> gsm48_mm.c:1348 Freeing MM Connection <0004> gsm48_mm.c:1291 (ref 1) new state CONN_PEND -> IDLE <0005> gsm48_cc.c:2122 (ms 1) Received 'MMCC_ERR_IND' in CC state MM_CONNECTION_PEND <0005> gsm48_cc.c:189 (ms 1 ti ff) Sending 'MNCC_REL_IND' to MNCC. <0007> mnccms.c:336 Call has been released (cause 16) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wbg_1000 at yahoo.com Tue May 3 05:39:23 2011 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Mon, 2 May 2011 22:39:23 -0700 (PDT) Subject: mobile - making a call In-Reply-To: <558647.10314.qm@web112114.mail.gq1.yahoo.com> Message-ID: <361316.71209.qm@web112116.mail.gq1.yahoo.com> So is this normal at the current stage of the project or there's something wrong with my setup ? (and all the calls where suppose to advance to the alert phase) Cheers. --- On Mon, 5/2/11, eisencah eisenach wrote: From: eisencah eisenach Subject: mobile - making a call To: baseband-devel at lists.osmocom.org Date: Monday, May 2, 2011, 1:17 PM Hi. I'm using mobile application (sylvain/testing branch) to initiate calls. My experience is that the call si succesfull in about 20% of cases. Most of the time the connection seems to be lost after receiving the AUTHENTICATION REQUEST message. Has anyone else had this experience, it has to do with the power measurements above? Thanks, Mihai. [0;m[1;33m<0005> gsm48_cc.c:496 Sending MMCC_EST_REQ [0;m[1;32m<0004> gsm48_mm.c:3568 (ms 1) Received 'MMCC_EST_REQ' event in state MM idle [0;m[1;32m<0004> gsm48_mm.c:3571 -> substate normal service [0;m[1;32m<0004> gsm48_mm.c:3573 -> callref 1, transaction_id 255 [0;m[1;32m<0004> gsm48_mm.c:2873 Init MM Connection. [0;m[1;32m<0004> gsm48_mm.c:1332 New MM Connection (proto 0x03 trans_id 255 ref 1) [0;m[1;32m<0004> gsm48_mm.c:1291 (ref 1) new state IDLE -> CONN_PEND [0;m[1;32m<0004> gsm48_mm.c:2650 CM SERVICE REQUEST (cause 9) [0;m[1;32m<0004> gsm48_mm.c:2681 -> Using TMSI [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_EST_REQ' received in state idle [0;m[1;37m<000d> gsm48_rr.c:1181 Establish radio link due to mobility management request [0;m[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' [0;m[34m<0003> gsm322.c:2959 Going to camping frequency 47. [0;m[34m<0003> gsm322.c:252 Sync to ARFCN=47 rxlev=-61 (Sysinfo, ccch mode NON-COMB) [0;m[1;34m<0001> gsm48_rr.c:363 new state idle -> connection pending [0;m[1;34m<0001> gsm48_rr.c:1313 CHANNEL REQUEST: e0 (Orig TCH/F) [0;m[1;32m<0004> gsm48_mm.c:887 new state MM IDLE, normal service -> wait for RR connection (MM connection) [0;m[34m<0003> gsm322.c:2434 Channel synched. (ARFCN=47, snr=16, BSIC=33) [0;m[1;34m<0001> gsm322.c:2461 using DSC of 90 [0;m[34m<0003> gsm48_rr.c:4541 Channel provides data. [0;m[1;34m<0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 5) [0;m[1;34m<0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 0 ra 0xed) [0;m[1;34m<0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) [0;m[1;34m<0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 4) [0;m[1;34m<0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 217 ra 0xed) [0;m[1;34m<0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) [0;m[1;34m<0001> gsm48_rr.c:2258 IMMEDIATE ASSIGNMENT: [0;m[1;34m<0001> gsm48_rr.c:2270? (ta 1/553m ra 0xed chan_nr 0x41 MAIO 2 HSN 36 TS 1 SS 0 TSC 1) [0;m[1;34m<0001> gsm48_rr.c:2204 request ed matches (fn=4,24,16) [0;m[1;34m<0001> gsm48_rr.c:2304 resetting scheduler [0;m[1;34m<0001> gsm48_rr.c:2858 decoding mobile allocation [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #0: 31 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #1: 44 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #2: 47 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #3: 57 [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 0 (bit 31) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 1 (bit 44) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 2 (bit 47) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 3 (bit 57) [0;m[1;34m<0001> gsm48_rr.c:3019 sending establish message [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[1;34m<0001> gsm48_rr.c:2763 setting indicated TA 1 (actual TA 1) [0;m[1;34m<0001> gsm48_rr.c:2774 using last SACCH timeout 16 [0;m[1;34m<0001> gsm48_rr.c:774 stopping pending timer T_meas [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=1 meas-invalid=1 rxlev-full=-110 rxlev-sub=-110 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:2796 establishing channel in dedicated mode [0;m[1;34m<0001> gsm48_rr.c:2800? Channel type 64, subch 0, ts 1, mode 0, cipher 1 [0;m[1;34m<0001> gsm48_rr.c:363 new state connection pending -> dedicated [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_EST_CNF' from RR in state wait for RR connection (MM connection) [0;m[1;32m<0004> gsm48_mm.c:431 starting T3230 (MM connection timeout) with 15.0 seconds [0;m[1;32m<0004> gsm48_mm.c:897 new state wait for RR connection (MM connection) -> wait for outgoing MM connection [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 1 (actual ta 1) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:1828 New SYSTEM INFORMATION 5 [0;m[1;34m<0001> gsm48_rr.c:1583 Complete set of SI5* for BA(0) [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 1 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 3 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 6 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 13 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 17 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 19 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 20 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 21 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 24 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 26 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 30 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 33 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 36 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 37 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 40 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 41 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 42 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 47 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 49 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 58 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 59 [0;m[1;32m<0004> gsm48_mm.c:4083 (ms 1) Received 'MM_EVENT_SYSINFO' event in state wait for outgoing MM connection [0;m[34m<0003> gsm322.c:2104 Sysinfo of selected cell is updated. [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:468 stopping pending (periodic loc. upd. delay) timer T3212 [0;m[1;32m<0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) [0;m[1;32m<0004> subscriber.c:898 Generating KEY at SIM [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-60 snr=11 ber= 27 LAI=226 01 2b96 ID=e328 TA=0 pwr=5 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=0 meas-invalid=0 rxlev-full=-60 rxlev-sub=-60 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 6 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 17 LAI=226 01 2b96 ID=e328 TA=0 pwr=6 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=6 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 7 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 7 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber=? 0 LAI=226 01 2b96 ID=e328 TA=0 pwr=7 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=7 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 18 LAI=226 01 2b96 ID=e328 TA=0 pwr=8 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=8 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 49 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) [0;m[1;32m<0004> subscriber.c:898 Generating KEY at SIM [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 32 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 41 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 74 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber=? 9 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 35 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:3174 channel release request with cause 0x00) [0;m[1;34m<0001> gsm48_rr.c:363 new state dedicated -> release pending [0;m[1;34m<0001> gsm48_rr.c:738 starting T3110 with 1.500 seconds [0;m[1;37m<000d> gsm48_rr.c:4666 Requested channel aborted [0;m[1;34m<0001> gsm48_rr.c:798 stopping pending timer T3110 [0;m[1;34m<0001> gsm48_rr.c:363 new state release pending -> idle [0;m[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection in state 'C3 camped normally' [0;m[34m<0003> gsm322.c:541 new state 'C3 camped normally' -> 'C5 choose cell' [0;m[34m<0003> gsm322.c:2820 No BA range(s), try sysinfo. [0;m[34m<0003> gsm322.c:2859 free sysinfo arfcn=47 [0;m[34m<0003> gsm322.c:2859 free sysinfo arfcn=66 [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_REL_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:495 stopping pending (MM connection timeout) timer T3230 [0;m[1;32m<0004> gsm48_mm.c:1367 Release any MM Connection [0;m[1;32m<0004> gsm48_mm.c:1348 Freeing MM Connection [0;m[1;32m<0004> gsm48_mm.c:1291 (ref 1) new state CONN_PEND -> IDLE [0;m[1;33m<0005> gsm48_cc.c:2122 (ms 1) Received 'MMCC_ERR_IND' in CC state MM_CONNECTION_PEND [0;m[1;33m<0005> gsm48_cc.c:189 (ms 1 ti ff) Sending 'MNCC_REL_IND' to MNCC. [0;m[1;37m<0007> mnccms.c:336 Call has been released (cause 16) -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue May 3 06:32:56 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 3 May 2011 08:32:56 +0200 Subject: mobile - making a call In-Reply-To: <361316.71209.qm@web112116.mail.gq1.yahoo.com> References: <558647.10314.qm@web112114.mail.gq1.yahoo.com> <361316.71209.qm@web112116.mail.gq1.yahoo.com> Message-ID: > So is this normal at the current stage of the project or there's something wrong with my setup ? (and all the calls where suppose to advance to the alert phase) Nope, it should work. No idea why it doesn't for you. Sylvain From wbg_1000 at yahoo.com Tue May 3 10:02:58 2011 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Tue, 3 May 2011 03:02:58 -0700 (PDT) Subject: mobile - making a call In-Reply-To: Message-ID: <486968.15221.qm@web112110.mail.gq1.yahoo.com> The difference between the cases that work and the ones that don't is : GOOD CASE: <0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 0) <0004> subscriber.c:898 Generating KEY at SIM <000e> sim.c:209 got new job: SIM_JOB_RUN_GSM_ALGO (handle=00000006) <000e> sim.c:538 RUN GSM ALGORITHM <000e> sim.c:187 sending APDU (class 0xa0, ins 0x88) BAD CASE: <0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) <0004> subscriber.c:898 Generating KEY at SIM <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) <0001> gsm48_rr.c:4490 Indicated tx_power 5 So is as if the message for the sim job doesn't get pulled from the queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears.? Must say the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz celeron with ubuntu 6.10) , and It gets slowed down when running the hole thing. Can that be the cause? Mihai. --- On Tue, 5/3/11, Sylvain Munaut <246tnt at gmail.com> wrote: From: Sylvain Munaut <246tnt at gmail.com> Subject: Re: mobile - making a call To: "eisencah eisenach" Cc: baseband-devel at lists.osmocom.org Date: Tuesday, May 3, 2011, 9:32 AM > So is this normal at the current stage of the project or there's something wrong with my setup ? (and all the calls where suppose to advance to the alert phase) Nope, it should work. No idea why it doesn't for you. ? ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Tue May 3 07:15:31 2011 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 3 May 2011 09:15:31 +0200 Subject: AW: mobile - making a call Message-ID: hi, can you try a different sim / different network? andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From wbg_1000 at yahoo.com Wed May 4 13:58:04 2011 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Wed, 4 May 2011 06:58:04 -0700 (PDT) Subject: mobile - making a call In-Reply-To: <20110504085923.GA2911@prithivi.gnumonks.org> Message-ID: <802166.91765.qm@web112119.mail.gq1.yahoo.com> Done some more digging in the logs and it seems the sim state machine has locked earlier (when attaching to the network)? while waiting for some response on UPDATE BINARY. Does this sounds familiar to anyone? :) GOOD CASE: <0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE <0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated <0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) <000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) <000e> sim.c:241 SELECT (file=0x6f20) <000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) <000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) <000e> sim.c:949 command successfull <000e> sim.c:571 GET RESPONSE (len=15) <000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) <000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) <000e> sim.c:949 command successfull <000e> sim.c:294 UPDATE BINARY (offset=0 len=9) <000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) <000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00) <000e> sim.c:949 command successfull <000e> sim.c:151 sending result to callback function (type=0) <0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) BAD CASE: <0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE <0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated <0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) <000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) <000e> sim.c:241 SELECT (file=0x6f20) <000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) <000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) <000e> sim.c:949 command successfull <000e> sim.c:571 GET RESPONSE (len=15) <000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) <000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) <000e> sim.c:949 command successfull <000e> sim.c:294 UPDATE BINARY (offset=0 len=9) <000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) <0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated --- On Wed, 5/4/11, Harald Welte wrote: From: Harald Welte Subject: Re: mobile - making a call To: "eisencah eisenach" Date: Wednesday, May 4, 2011, 11:59 AM On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote: > So is as if the message for the sim job doesn't get pulled from the > queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears.? Must say > the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz > celeron with ubuntu 6.10) , and It gets slowed down when running the > hole thing. Can that be the cause?? Mihai. The L1CTL protocol goes through a unix domain socket, and you can trace it in either osmocon or in the mobile program itself.? It should be relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile, or if it is lost, where it is lost. -- - Harald Welte ? ? ? ? ???http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon May 2 15:26:01 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 2 May 2011 17:26:01 +0200 Subject: RMS / FSF / OsmocomBB / Free Software GSM phone Message-ID: <20110502152601.GJ3301@prithivi.gnumonks.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Some months ago, Richard Stallman (rms) has contacted me regarding my work with OsmocomBB. As it is not a big surprise to us, he is really interested in the project. After all, it would be the first mobile phone that he himself would be able to use, given that there is no proprietary software on the baseband anymore. And of course it would enable loads of other freedom-loving users to finally have an alternative to the proprietary telephony world. Here in Morocco, I've had some further discussion on the topic face to face with him, and he is sort of unhappy with the fact that nobody is working on making an actual self-contained phone (no matter how simple or limited in features) that can be used by a regular user as 'just a phone'. I explained to him that our motivation is mostly a different one (research, security, GSM-attached PBX, etc.) and thus there is no intrinsic motivation to work towards a more user-friendly version. Furthermore, we are system level hackers with an interest in communications, not particularly people who like to work on a UI or usability. So we agreed to make a public call for volunteers to wokr on that aspect of the phone. I understand this will likely cause some effort on our side (fencing off poeple who don't have the neccessary skills, integrating such code, finally deciding on a RTOS to use, etc.). However, I more or less see it as my (and our?) duty to realize the potential of our protocol stack and baseband firmware. Next to all our own self-motivated personal interestes, there is a bigger cause that we can help along: Free Software based telephony. So the least we can do is to try to find somebody who can work on that part, and help developer[s] to interact with our code. It's the question of whether we are just hacking away on our personal little pet, or if we try to achieve something bigger. I've already drafted a version of the 'job description' and with some luck the FSF will soon publish it, reaching out beyond our existing small Osmocom community. e will try to draft a similar job description related to MS-side GPRS support (L1, RLC/MAC, ..). That would be yet another area where we would appreciate some contribution, and which eventually be important beyond our existing voice telephony capabilities. Regards, Harald - -- - - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFNvs0JXaXGVTD0i/8RArkDAKCONleE9HJ2i1jp7L/XnMY0YweIjACbB8Lz puH7X4lkqY8AqzU0SAlOAxM= =Cmo8 -----END PGP SIGNATURE----- From sweisman at pobox.com Mon May 2 17:20:58 2011 From: sweisman at pobox.com (Scott Weisman) Date: Mon, 2 May 2011 20:20:58 +0300 Subject: RMS / FSF / OsmocomBB / Free Software GSM phone In-Reply-To: <20110502152601.GJ3301@prithivi.gnumonks.org> References: <20110502152601.GJ3301@prithivi.gnumonks.org> Message-ID: I think this is awesome. I would try to put in some help if I could, as long as someone else told me what to do (:-). I have experience with fairly low-level C programming and I did have a job writing laboratory control software (in Forth) when I was in college (1980s). I have several Osmocom-class phones I have purchased over the last year. I did run the hello world app on a phone, just to make sure I could. I compiled the tool chain myself with a script I found and customized that made a really clean install (let me know if anyone is interested, but there are better scripts out there now). Most of the cell stuff talked about on this list is above my head, though I have gained a basic understanding of what's going on. I found the c3 lectures fascinating, and watched quite a few. I'm definitely interested in doing something for this project if I can. Harald, I know you and the other people contributing to this project are interested in this more from a research and understanding perspective. But I also agree with RMS about the need for a fully open phone. You guys have revealed just how weak the GSM network is, with its closed stack assuming that all participants were noble knights who always followed the rules (:-). It actually concerns me just what the telcos might be capable of doing, especially after seeing the talks on silent SMS messaging. There's no good reason for this software to be so closed. This is the big one too. There are lots of other areas where proprietary software is dominant, but few affect as many people directly as cellular phones. I also have no doubt that a usable phone would get a LOT of attention. Could help encourage efforts in other areas. Color laser printers are another area of concern, because of the embedded ID on every printed page. I am not surprised in the least that RMS is interested, even very interested. Scott On Mon, May 2, 2011 at 6:26 PM, Harald Welte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > Some months ago, Richard Stallman (rms) has contacted me regarding > my work with OsmocomBB. As it is not a big surprise to us, he is > really interested in the project. After all, it would be the first > mobile phone that he himself would be able to use, given that there > is no proprietary software on the baseband anymore. And of course > it would enable loads of other freedom-loving users to finally have > an alternative to the proprietary telephony world. > > Here in Morocco, I've had some further discussion on the topic face to > face with him, and he is sort of unhappy with the fact that nobody is > working on making an actual self-contained phone (no matter how simple > or limited in features) that can be used by a regular user as 'just a > phone'. > > I explained to him that our motivation is mostly a different one > (research, security, GSM-attached PBX, etc.) and thus there is no > intrinsic motivation to work towards a more user-friendly version. > Furthermore, we are system level hackers with an interest in > communications, not particularly people who like to work on a UI > or usability. > > So we agreed to make a public call for volunteers to wokr on that aspect > of the phone. I understand this will likely cause some effort on our > side (fencing off poeple who don't have the neccessary skills, > integrating such code, finally deciding on a RTOS to use, etc.). > > However, I more or less see it as my (and our?) duty to realize the > potential of our protocol stack and baseband firmware. Next to all > our own self-motivated personal interestes, there is a bigger cause > that we can help along: Free Software based telephony. So the least > we can do is to try to find somebody who can work on that part, and > help developer[s] to interact with our code. > > It's the question of whether we are just hacking away on our personal > little pet, or if we try to achieve something bigger. > > I've already drafted a version of the 'job description' and with some > luck the FSF will soon publish it, reaching out beyond our existing > small Osmocom community. > > e will try to draft a similar job description related to MS-side GPRS > support (L1, RLC/MAC, ..). That would be yet another area where we > would appreciate some contribution, and which eventually be important > beyond our existing voice telephony capabilities. > > Regards, > Harald > - -- > - - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iD8DBQFNvs0JXaXGVTD0i/8RArkDAKCONleE9HJ2i1jp7L/XnMY0YweIjACbB8Lz > puH7X4lkqY8AqzU0SAlOAxM= > =Cmo8 > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon May 2 18:13:50 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 2 May 2011 20:13:50 +0200 Subject: RMS / FSF / OsmocomBB / Free Software GSM phone In-Reply-To: <20110502152601.GJ3301@prithivi.gnumonks.org> References: <20110502152601.GJ3301@prithivi.gnumonks.org> Message-ID: Hi, >?After all, it would be the first > mobile phone that he himself would be able to use, given that there > is no proprietary software on the baseband anymore. Well, if you're extremist about it, there is still the DSP. Not much we can do about it without making our own ASIC tough :p > Here in Morocco, I've had some further discussion on the topic face to > face with him, and he is sort of unhappy with the fact that nobody is > working on making an actual self-contained phone (no matter how simple > or limited in features) that can be used by a regular user as 'just a > phone'. Well, even if we have reached major milestones (IMHO) and are able to make actual phone calls, there is still a bunch of things missing even for voice / SMS and reliability problems in some cases. Besides the UI there is also a lot of things that need to be done to be usable as a phone, like being able to charge the battery, or at least not drain it in a few hours by having all chips fully powered on all the time. > e will try to draft a similar job description related to MS-side GPRS > support (L1, RLC/MAC, ..). ?That would be yet another area where we > would appreciate some contribution, and which eventually be important > beyond our existing voice telephony capabilities. The RLC/MAC layer can certainly be useful for a lot of reasons (both MS and BTS side), but is anyone seriously gonna use GPRS non-edge ? Cheers, Sylvain From peter at stuge.se Mon May 2 18:36:13 2011 From: peter at stuge.se (Peter Stuge) Date: Mon, 2 May 2011 20:36:13 +0200 Subject: RMS / FSF / OsmocomBB / Free Software GSM phone In-Reply-To: References: <20110502152601.GJ3301@prithivi.gnumonks.org> Message-ID: <20110502183613.27705.qmail@stuge.se> Sylvain Munaut wrote: > > it would be the first mobile phone that he himself would be able > > to use > > Well, if you're extremist about it, there is still the DSP. Yes why I wanted to have a go at making modem. Unfortunately not top priority, so it's going real slow. (But tomorrow I'll make some RF tests with real simple trx and soft modems. Fun!) > Not much we can do about it without making our own ASIC tough :p Getting a modem to work at all would be the first step anyway, then optimize for size and cost, ideally of course reusing cheap hardware already on the market. //Peter From 246tnt at gmail.com Mon May 2 18:40:07 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 2 May 2011 20:40:07 +0200 Subject: RMS / FSF / OsmocomBB / Free Software GSM phone In-Reply-To: <20110502183613.27705.qmail@stuge.se> References: <20110502152601.GJ3301@prithivi.gnumonks.org> <20110502183613.27705.qmail@stuge.se> Message-ID: Hi, >> Not much we can do about it without making our own ASIC tough :p > > Getting a modem to work at all would be the first step anyway, then > optimize for size and cost, ideally of course reusing cheap hardware > already on the market. I don't think it's that hard given we have working examples. TX is easy. RX is already implemented in RX The main part is having properly timed TX/RX. Sylvain From laforge at gnumonks.org Mon May 2 20:51:54 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 2 May 2011 22:51:54 +0200 Subject: RMS / FSF / OsmocomBB / Free Software GSM phone In-Reply-To: References: <20110502152601.GJ3301@prithivi.gnumonks.org> Message-ID: <20110502205154.GB3477@prithivi.gnumonks.org> Hi Sylvain, On Mon, May 02, 2011 at 08:13:50PM +0200, Sylvain Munaut wrote: > >?After all, it would be the first > > mobile phone that he himself would be able to use, given that there > > is no proprietary software on the baseband anymore. > > Well, if you're extremist about it, there is still the DSP. > Not much we can do about it without making our own ASIC tough :p I do not think the DSP is an issue, as it is programmed by mask ROM. As far as I understand RMS' position, any mask ROM code on a separate processor is tolerable for him. Just code that resides in FLASH or other r/w memory is required as Free Software. > Well, even if we have reached major milestones (IMHO) and are able to > make actual phone calls, of course, I didn't want to say that the project has not reached milestones or is not making progress. I just wanted to say that the speed has slowed down and recent developments go in other areas than to make a 'stupid phone': sniffing, running phone as BTS, fuzzing/security stuff, general reasearch, lcr-integration, etc. > there is still a bunch of things missing even for voice / SMS and > reliability problems in some cases. Sure. RMS and I were not talking about a 'end user production ready' phone, but something that -even though initially unreliable and very limited in functionality- can be used as a phone. Progress in stabilization, testing in real networks etc. can be made from that point on. > Besides the UI there is also a lot of things that need to be done to > be usable as a phone, like being able to charge the battery, roh has done some battery charging work in the past, but i guess it was never merged. > or at least not drain it in a few hours by having all chips fully > powered on all the time. i'm not so sure if that absolutely has to come first. A Free Software phone that runs for a couple of hours is better than none at all. The power management can be improved gradually. > The RLC/MAC layer can certainly be useful for a lot of reasons (both > MS and BTS side), but is anyone seriously gonna use GPRS non-edge ? It depends for what. You have to keep in mind the screen real estate and processing power. So for e.g. updating your identi.ca, or using som instant messenger instead of SMS it would be sufficient. Also, the RLC/MAC will be independent of the L1 (like our GSM L2/L3 is), and it could be used on EDGE capable devices if other baseband processors are supported later on. I seriously hope the Calypso is not the last chip we support. Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From rm at deconfused.org Mon May 2 21:32:29 2011 From: rm at deconfused.org (Ryan Mullen) Date: Mon, 2 May 2011 17:32:29 -0400 Subject: RMS / FSF / OsmocomBB / Free Software GSM phone In-Reply-To: <20110502152601.GJ3301@prithivi.gnumonks.org> References: <20110502152601.GJ3301@prithivi.gnumonks.org> Message-ID: Hello, On Mon, May 2, 2011 at 11:26 AM, Harald Welte wrote: > Some months ago, Richard Stallman (rms) has contacted me regarding > my work with OsmocomBB. ?As it is not a big surprise to us, he is > really interested in the project. ?After all, it would be the first > mobile phone that he himself would be able to use, given that there > is no proprietary software on the baseband anymore. ? And of course > it would enable loads of other freedom-loving users to finally have > an alternative to the proprietary telephony world. For what it's worth, I work for an embedded systems shop doing microcontroller-level C, and would be happy to lend a small hand if the need arises. I don't have very much experience, but this is a project that I hope succeeds and I'll do what I can to see it happen. Regards, Ryan From laforge at gnumonks.org Wed May 4 14:36:26 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 4 May 2011 16:36:26 +0200 Subject: Anyone based in India on this list? Students? Message-ID: <20110504143626.GL2911@prithivi.gnumonks.org> I'm looking for somebody in India who has a deep GSM interest and who is preferrably a student. If you're quick, I have a free giveaway for you. Please simply e-mail me, details will follow. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sweisman at pobox.com Thu May 5 07:15:39 2011 From: sweisman at pobox.com (Scott Weisman) Date: Thu, 5 May 2011 10:15:39 +0300 Subject: Anyone based in India on this list? Students? In-Reply-To: <20110504143626.GL2911@prithivi.gnumonks.org> References: <20110504143626.GL2911@prithivi.gnumonks.org> Message-ID: Why India? What are you giving away? What tasks are you looking to get done? On Wed, May 4, 2011 at 5:36 PM, Harald Welte wrote: > I'm looking for somebody in India who has a deep GSM interest and who > is preferrably a student. If you're quick, I have a free giveaway for > you. > > Please simply e-mail me, details will follow. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu May 5 07:34:21 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 5 May 2011 09:34:21 +0200 Subject: Anyone based in India on this list? Students? In-Reply-To: References: <20110504143626.GL2911@prithivi.gnumonks.org> Message-ID: <20110505073421.GY2911@prithivi.gnumonks.org> Hi, On Thu, May 05, 2011 at 10:15:39AM +0300, Scott Weisman wrote: > Why India? What are you giving away? What tasks are you looking to get done? There are no tasks to get done. I just knew a friend in India with a book on GSM history that he wanted to give away to somebody related to OsmocomBB who would be interested. India: Since the book is located in India. I've already found a recipient for the book. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From wolfram at the-dreams.de Wed May 4 20:58:12 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Wed, 4 May 2011 22:58:12 +0200 Subject: [PATCH 0/5] merge mtk-loader to master Message-ID: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> The first four patches remove some hardcoded calypso-dependencies (as discussed on the list). The final one then adds the mtk-stuff with comments from Sylvain addressed (hopefully). The new mtk-loader was succesfully tested on my Sciphone G2 by loading and executing a bootloader. The compal loaders still compile fine (and no code was changed there). This should get rid of the branches remotes/origin/steve-m/loader_sciphone remotes/origin/steve-m/mtk_hack and should ease merging new platforms in general a bit more. Regards, Wolfram Wolfram Sang (5): comm: msgb: don't set backlight on error lib: move delay.c from calypso to lib cfi_flash: delete unused defines uart.h: move header out of calypso-directory target/boards: add infrastructure for loaders for Mediatek platforms src/Makefile | 8 +- src/target/firmware/Makefile.mtk | 33 ++ src/target/firmware/apps/loader/main.c | 2 +- src/target/firmware/apps/loader_mtk/main.c | 366 ++++++++++++++++++++ src/target/firmware/board/compal_e86/init.c | 2 +- src/target/firmware/board/compal_e88/init.c | 2 +- src/target/firmware/board/compal_e99/init.c | 2 +- src/target/firmware/board/gta0x/init.c | 2 +- src/target/firmware/board/mediatek/macros.S | 76 +++++ src/target/firmware/board/mediatek/ram.lds | 112 +++++++ src/target/firmware/board/mediatek/start.ram.S | 26 ++ src/target/firmware/board/mediatek/uart.c | 426 ++++++++++++++++++++++++ src/target/firmware/board/mt62xx/init.c | 139 ++++++++ src/target/firmware/board/pirelli_dpl10/init.c | 2 +- src/target/firmware/calypso/Makefile | 2 +- src/target/firmware/calypso/delay.c | 16 - src/target/firmware/calypso/uart.c | 2 +- src/target/firmware/comm/msgb.c | 1 - src/target/firmware/comm/sercomm.c | 2 +- src/target/firmware/comm/sercomm_cons.c | 2 +- src/target/firmware/flash/cfi_flash.c | 5 - src/target/firmware/include/calypso/uart.h | 32 -- src/target/firmware/include/mtk/emi.h | 42 +++ src/target/firmware/include/mtk/mt6235.h | 74 ++++ src/target/firmware/include/mtk/system.h | 195 +++++++++++ src/target/firmware/include/uart.h | 32 ++ src/target/firmware/lib/Makefile | 2 +- src/target/firmware/lib/console.c | 2 +- src/target/firmware/lib/delay.c | 16 + 29 files changed, 1556 insertions(+), 67 deletions(-) create mode 100644 src/target/firmware/Makefile.mtk create mode 100644 src/target/firmware/apps/loader_mtk/main.c create mode 100644 src/target/firmware/board/mediatek/macros.S create mode 100644 src/target/firmware/board/mediatek/ram.lds create mode 100644 src/target/firmware/board/mediatek/start.ram.S create mode 100644 src/target/firmware/board/mediatek/uart.c create mode 100644 src/target/firmware/board/mt62xx/init.c delete mode 100644 src/target/firmware/calypso/delay.c delete mode 100644 src/target/firmware/include/calypso/uart.h create mode 100644 src/target/firmware/include/mtk/emi.h create mode 100644 src/target/firmware/include/mtk/mt6235.h create mode 100644 src/target/firmware/include/mtk/system.h create mode 100644 src/target/firmware/include/uart.h create mode 100644 src/target/firmware/lib/delay.c -- 1.7.2.5 From wolfram at the-dreams.de Wed May 4 20:58:13 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Wed, 4 May 2011 22:58:13 +0200 Subject: [PATCH 1/5] comm: msgb: don't set backlight on error In-Reply-To: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> References: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> Message-ID: <1304542697-5397-2-git-send-email-wolfram@the-dreams.de> Removes the dependency to calypso and makes place for a generic board_panic to be added later. Signed-off-by: Wolfram Sang --- src/target/firmware/comm/msgb.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/target/firmware/comm/msgb.c b/src/target/firmware/comm/msgb.c index ff18e65..792abc6 100644 --- a/src/target/firmware/comm/msgb.c +++ b/src/target/firmware/comm/msgb.c @@ -60,7 +60,6 @@ void *_talloc_zero(void *ctx, unsigned int size, const char *name) } } cons_puts("unable to allocate msgb\n"); - bl_level(++i % 50); delay_ms(50); } panic: -- 1.7.2.5 From wolfram at the-dreams.de Wed May 4 20:58:14 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Wed, 4 May 2011 22:58:14 +0200 Subject: [PATCH 2/5] lib: move delay.c from calypso to lib In-Reply-To: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> References: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> Message-ID: <1304542697-5397-3-git-send-email-wolfram@the-dreams.de> Nothing calypso-related in there and needed for Mediatek, too. Signed-off-by: Wolfram Sang --- src/target/firmware/calypso/Makefile | 2 +- src/target/firmware/calypso/delay.c | 16 ---------------- src/target/firmware/lib/Makefile | 2 +- src/target/firmware/lib/delay.c | 16 ++++++++++++++++ 4 files changed, 18 insertions(+), 18 deletions(-) delete mode 100644 src/target/firmware/calypso/delay.c create mode 100644 src/target/firmware/lib/delay.c diff --git a/src/target/firmware/calypso/Makefile b/src/target/firmware/calypso/Makefile index c0620ed..610a82c 100644 --- a/src/target/firmware/calypso/Makefile +++ b/src/target/firmware/calypso/Makefile @@ -1,4 +1,4 @@ LIBRARIES+=calypso calypso_DIR=calypso -calypso_SRCS=arm.c buzzer.c clock.c delay.c dma.c dsp.c du.c i2c.c irq.c rtc.c sim.c spi.c tpu.c tsp.c keypad.c misc.c timer.c backlight.c uart.c uwire.c +calypso_SRCS=arm.c buzzer.c clock.c dma.c dsp.c du.c i2c.c irq.c rtc.c sim.c spi.c tpu.c tsp.c keypad.c misc.c timer.c backlight.c uart.c uwire.c diff --git a/src/target/firmware/calypso/delay.c b/src/target/firmware/calypso/delay.c deleted file mode 100644 index 443ca82..0000000 --- a/src/target/firmware/calypso/delay.c +++ /dev/null @@ -1,16 +0,0 @@ -#include - -/* FIXME: We need properly calibrated delay loops at some point! */ -void delay_us(unsigned int us) -{ - volatile unsigned int i; - - for (i= 0; i < us*4; i++) { i; } -} - -void delay_ms(unsigned int ms) -{ - volatile unsigned int i; - - for (i= 0; i < ms*1300; i++) { i; } -} diff --git a/src/target/firmware/lib/Makefile b/src/target/firmware/lib/Makefile index 987857c..83f9966 100644 --- a/src/target/firmware/lib/Makefile +++ b/src/target/firmware/lib/Makefile @@ -2,6 +2,6 @@ LIBRARIES+=mini mini_DIR=lib mini_SRCS=vsprintf.c string.c ctype.c printf.c console.c ctors.c \ - changebit.S clearbit.S div64.S lib1funcs.S memcpy.S memset.S setbit.S testchangebit.S testclearbit.S testsetbit.S + changebit.S clearbit.S delay.c div64.S lib1funcs.S memcpy.S memset.S setbit.S testchangebit.S testclearbit.S testsetbit.S diff --git a/src/target/firmware/lib/delay.c b/src/target/firmware/lib/delay.c new file mode 100644 index 0000000..443ca82 --- /dev/null +++ b/src/target/firmware/lib/delay.c @@ -0,0 +1,16 @@ +#include + +/* FIXME: We need properly calibrated delay loops at some point! */ +void delay_us(unsigned int us) +{ + volatile unsigned int i; + + for (i= 0; i < us*4; i++) { i; } +} + +void delay_ms(unsigned int ms) +{ + volatile unsigned int i; + + for (i= 0; i < ms*1300; i++) { i; } +} -- 1.7.2.5 From wolfram at the-dreams.de Wed May 4 20:58:15 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Wed, 4 May 2011 22:58:15 +0200 Subject: [PATCH 3/5] cfi_flash: delete unused defines In-Reply-To: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> References: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> Message-ID: <1304542697-5397-4-git-send-email-wolfram@the-dreams.de> Signed-off-by: Wolfram Sang --- src/target/firmware/flash/cfi_flash.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/src/target/firmware/flash/cfi_flash.c b/src/target/firmware/flash/cfi_flash.c index d255694..69369d5 100644 --- a/src/target/firmware/flash/cfi_flash.c +++ b/src/target/firmware/flash/cfi_flash.c @@ -28,11 +28,6 @@ #include #include -/* XXX: memdump_range() */ -#include -#include -#include - /* XXX: strings must always be in ram */ #if 0 #define puts(...) -- 1.7.2.5 From wolfram at the-dreams.de Wed May 4 20:58:16 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Wed, 4 May 2011 22:58:16 +0200 Subject: [PATCH 4/5] uart.h: move header out of calypso-directory In-Reply-To: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> References: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> Message-ID: <1304542697-5397-5-git-send-email-wolfram@the-dreams.de> Everything defined is a pretty generic interface and can be used by mediatek, too. Signed-off-by: Wolfram Sang --- src/target/firmware/apps/loader/main.c | 2 +- src/target/firmware/board/compal_e86/init.c | 2 +- src/target/firmware/board/compal_e88/init.c | 2 +- src/target/firmware/board/compal_e99/init.c | 2 +- src/target/firmware/board/gta0x/init.c | 2 +- src/target/firmware/board/pirelli_dpl10/init.c | 2 +- src/target/firmware/calypso/uart.c | 2 +- src/target/firmware/comm/sercomm.c | 2 +- src/target/firmware/comm/sercomm_cons.c | 2 +- src/target/firmware/include/calypso/uart.h | 32 ------------------------ src/target/firmware/include/uart.h | 32 ++++++++++++++++++++++++ src/target/firmware/lib/console.c | 2 +- 12 files changed, 42 insertions(+), 42 deletions(-) delete mode 100644 src/target/firmware/include/calypso/uart.h create mode 100644 src/target/firmware/include/uart.h diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index 4e71d98..a948934 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -45,7 +45,7 @@ #include #include #include -#include +#include #include #include diff --git a/src/target/firmware/board/compal_e86/init.c b/src/target/firmware/board/compal_e86/init.c index 537702c..1de6193 100644 --- a/src/target/firmware/board/compal_e86/init.c +++ b/src/target/firmware/board/compal_e86/init.c @@ -37,7 +37,7 @@ #include #include #include -#include +#include #include #include diff --git a/src/target/firmware/board/compal_e88/init.c b/src/target/firmware/board/compal_e88/init.c index 54deb6a..a5bf880 100644 --- a/src/target/firmware/board/compal_e88/init.c +++ b/src/target/firmware/board/compal_e88/init.c @@ -36,7 +36,7 @@ #include #include #include -#include +#include #include #include diff --git a/src/target/firmware/board/compal_e99/init.c b/src/target/firmware/board/compal_e99/init.c index ed45c39..0c218a8 100644 --- a/src/target/firmware/board/compal_e99/init.c +++ b/src/target/firmware/board/compal_e99/init.c @@ -37,7 +37,7 @@ #include #include #include -#include +#include #include #include diff --git a/src/target/firmware/board/gta0x/init.c b/src/target/firmware/board/gta0x/init.c index 545250d..4f256ea 100644 --- a/src/target/firmware/board/gta0x/init.c +++ b/src/target/firmware/board/gta0x/init.c @@ -36,7 +36,7 @@ #include #include #include -#include +#include #include #include diff --git a/src/target/firmware/board/pirelli_dpl10/init.c b/src/target/firmware/board/pirelli_dpl10/init.c index cd38839..53fb257 100644 --- a/src/target/firmware/board/pirelli_dpl10/init.c +++ b/src/target/firmware/board/pirelli_dpl10/init.c @@ -37,7 +37,7 @@ #include #include #include -#include +#include #include #include diff --git a/src/target/firmware/calypso/uart.c b/src/target/firmware/calypso/uart.c index 394078d..d3ede4d 100644 --- a/src/target/firmware/calypso/uart.c +++ b/src/target/firmware/calypso/uart.c @@ -33,7 +33,7 @@ #include #include -#include +#include #define BASE_ADDR_UART_MODEM 0xffff5000 #define OFFSET_IRDA 0x800 diff --git a/src/target/firmware/comm/sercomm.c b/src/target/firmware/comm/sercomm.c index d7f6036..f9d5bfa 100644 --- a/src/target/firmware/comm/sercomm.c +++ b/src/target/firmware/comm/sercomm.c @@ -43,7 +43,7 @@ #include #include -#include +#include #endif diff --git a/src/target/firmware/comm/sercomm_cons.c b/src/target/firmware/comm/sercomm_cons.c index 987c992..a0dca40 100644 --- a/src/target/firmware/comm/sercomm_cons.c +++ b/src/target/firmware/comm/sercomm_cons.c @@ -26,7 +26,7 @@ #include -#include +#include #include #include diff --git a/src/target/firmware/include/calypso/uart.h b/src/target/firmware/include/calypso/uart.h deleted file mode 100644 index 7eb925e..0000000 --- a/src/target/firmware/include/calypso/uart.h +++ /dev/null @@ -1,32 +0,0 @@ -#ifndef _CAL_UART_H -#define _CAL_UART_H - -#include - -enum uart_baudrate { - UART_38400, - UART_57600, - UART_115200, - UART_230400, - UART_460800, - UART_614400, - UART_921600, -}; - -void uart_init(uint8_t uart, uint8_t interrupts); -void uart_putchar_wait(uint8_t uart, int c); -int uart_putchar_nb(uint8_t uart, int c); -int uart_getchar_nb(uint8_t uart, uint8_t *ch); -int uart_tx_busy(uint8_t uart); -int uart_baudrate(uint8_t uart, enum uart_baudrate bdrt); - -enum uart_irq { - UART_IRQ_TX_EMPTY, - UART_IRQ_RX_CHAR, -}; - -void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on); - -void uart_poll(uint8_t uart); - -#endif /* _CAL_UART_H */ diff --git a/src/target/firmware/include/uart.h b/src/target/firmware/include/uart.h new file mode 100644 index 0000000..81d7a15 --- /dev/null +++ b/src/target/firmware/include/uart.h @@ -0,0 +1,32 @@ +#ifndef _UART_H +#define _UART_H + +#include + +enum uart_baudrate { + UART_38400, + UART_57600, + UART_115200, + UART_230400, + UART_460800, + UART_614400, + UART_921600, +}; + +void uart_init(uint8_t uart, uint8_t interrupts); +void uart_putchar_wait(uint8_t uart, int c); +int uart_putchar_nb(uint8_t uart, int c); +int uart_getchar_nb(uint8_t uart, uint8_t *ch); +int uart_tx_busy(uint8_t uart); +int uart_baudrate(uint8_t uart, enum uart_baudrate bdrt); + +enum uart_irq { + UART_IRQ_TX_EMPTY, + UART_IRQ_RX_CHAR, +}; + +void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on); + +void uart_poll(uint8_t uart); + +#endif /* _UART_H */ diff --git a/src/target/firmware/lib/console.c b/src/target/firmware/lib/console.c index 2ec028a..7135ae2 100644 --- a/src/target/firmware/lib/console.c +++ b/src/target/firmware/lib/console.c @@ -23,7 +23,7 @@ #include #include #include -#include +#include #include -- 1.7.2.5 From wolfram at the-dreams.de Wed May 4 20:58:17 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Wed, 4 May 2011 22:58:17 +0200 Subject: [PATCH 5/5] target/boards: add infrastructure for loaders for Mediatek platforms In-Reply-To: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> References: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> Message-ID: <1304542697-5397-6-git-send-email-wolfram@the-dreams.de> We are just interested in the loaders here, no other applications needed. Split it from the compal-based phones. Add mt62xx as first user. Based on a patch by steve-m, but cleaned up and seperated from compal/calypso. Signed-off-by: Steve Markgraf Signed-off-by: Wolfram Sang --- src/Makefile | 8 +- src/target/firmware/Makefile.mtk | 32 ++ src/target/firmware/apps/loader_mtk/main.c | 366 ++++++++++++++++++++ src/target/firmware/board/mediatek/macros.S | 76 +++++ src/target/firmware/board/mediatek/ram.lds | 112 +++++++ src/target/firmware/board/mediatek/start.ram.S | 26 ++ src/target/firmware/board/mediatek/uart.c | 426 ++++++++++++++++++++++++ src/target/firmware/board/mt62xx/init.c | 139 ++++++++ src/target/firmware/include/mtk/emi.h | 42 +++ src/target/firmware/include/mtk/mt6235.h | 74 ++++ src/target/firmware/include/mtk/system.h | 195 +++++++++++ 11 files changed, 1495 insertions(+), 1 deletions(-) create mode 100644 src/target/firmware/Makefile.mtk create mode 100644 src/target/firmware/apps/loader_mtk/main.c create mode 100644 src/target/firmware/board/mediatek/macros.S create mode 100644 src/target/firmware/board/mediatek/ram.lds create mode 100644 src/target/firmware/board/mediatek/start.ram.S create mode 100644 src/target/firmware/board/mediatek/uart.c create mode 100644 src/target/firmware/board/mt62xx/init.c create mode 100644 src/target/firmware/include/mtk/emi.h create mode 100644 src/target/firmware/include/mtk/mt6235.h create mode 100644 src/target/firmware/include/mtk/system.h diff --git a/src/Makefile b/src/Makefile index 1b6f2f7..d6f556f 100644 --- a/src/Makefile +++ b/src/Makefile @@ -17,7 +17,7 @@ OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host LIBOSMOVTY_CFLAGS=-I$(TOPDIR)/shared/libosmocore/include \ LIBOSMOGSM_CFLAGS=-I$(TOPDIR)/shared/libosmocore/include -all: libosmocore-target nofirmware firmware +all: libosmocore-target nofirmware firmware mtk-firmware nofirmware: libosmocore-host layer23 osmocon gsmmap libosmocore-host: shared/libosmocore/build-host/src/.libs/libosmocore.la @@ -93,6 +93,10 @@ host/layer23/layer23: host/layer23/Makefile libosmocore-host firmware: libosmocore-target make -C target/firmware CROSS_COMPILE=$(CROSS_TOOL_PREFIX) +.PHONY: mtk-firmware +mtk-firmware: libosmocore-target + make -C target/firmware -f Makefile.mtk CROSS_COMPILE=$(CROSS_TOOL_PREFIX) + clean: make -C shared/libosmocore/build-host $@ @@ -100,10 +104,12 @@ clean: make -C host/layer23 $@ make -C host/osmocon $@ make -C target/firmware $@ + make -C target/firmware -f Makefile.mtk $@ distclean: rm -rf shared/libosmocore/build-host rm -rf shared/libosmocore/build-target make -C host/layer23 $@ make -C host/osmocon $@ +# 'firmware' also handles 'mtk-firmware' make -C target/firmware $@ diff --git a/src/target/firmware/Makefile.mtk b/src/target/firmware/Makefile.mtk new file mode 100644 index 0000000..30fa2fc --- /dev/null +++ b/src/target/firmware/Makefile.mtk @@ -0,0 +1,32 @@ +# List of all supported boards (meant to be overridden on command line) +BOARDS?=mt62xx + +# List of all applications (meant to be overridden on command line) +APPLICATIONS?=loader_mtk + +mtkram_LDS=board/mediatek/ram.lds +mtkram_OBJS=board/mediatek/start.ram.o + +mtk_COMMON_OBJS=board/mediatek/uart.o + +# Mediatek MT62xx +mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o +mt62xx_ENVIRONMENTS=mtkram + +# Global include path +INCLUDES=-Iinclude/ -I../../../include -I../../shared/libosmocore/include + +FLASH_OBJS=flash/cfi_flash.o + +# Objects that go in all applications +ANY_APP_OBJS+=$(FLASH_OBJS) + +# Various objects that are currently linked into all applications +ANY_APP_LIBS+=lib/libmini.a comm/libcomm.a ../../shared/libosmocore/build-target/src/.libs/libosmocore.a + +# Libraries are defined in subdirectories +-include comm/Makefile +-include lib/Makefile + +# Include rules +-include Makefile.inc diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c new file mode 100644 index 0000000..899d765 --- /dev/null +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -0,0 +1,366 @@ +/* + * boot loader for MTK phones (based on the calypso-version) + * + * (C) 2010 by Ingo Albrecht + * (C) 2011 by Wolfram Sang + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include + +#include + +#include + +#include +#include +#include + +#include "../loader/protocol.h" + +/* Main Program */ +const char *hr = + "======================================================================\n"; + +static void cmd_handler(uint8_t dlci, struct msgb *msg); + +int flag = 0; + +static void flush_uart(void) +{ + unsigned i; + for (i = 0; i < 500; i++) { + uart_poll(SERCOMM_UART_NR); + delay_ms(1); + } +} + +static void device_poweroff(void) +{ + flush_uart(); + writew(BBPU_MAGIC | RTC_BBPU_WRITE_EN, + MTK_RTC_BBPU); + writew(1, MTK_RTC_WRTGR); +} + +static void device_reset(void) +{ + flush_uart(); +} + +static void device_enter_loader(__unused unsigned char bootrom) +{ + flush_uart(); + delay_ms(2000); + void (*entry)( void ) = (void (*)(void))0; + entry(); +} + +static void device_jump(void *entry) +{ + flush_uart(); + + void (*f) (void) = (void (*)(void))entry; + f(); +} + +static void loader_send_simple(struct msgb *msg, uint8_t dlci, uint8_t command) +{ + msgb_put_u8(msg, command); + sercomm_sendmsg(dlci, msg); +} + +extern unsigned char _start; + +flash_t the_flash; + +extern void putchar_asm(uint32_t c); + +static const uint8_t phone_ack[] = { 0x1b, 0xf6, 0x02, 0x00, 0x41, 0x03, 0x42 }; + +int main(void) +{ + board_init (); + + /* Initialize HDLC subsystem */ + sercomm_init(); + + /* Say hi */ + puts("\n\nOSMOCOM Loader (revision " GIT_REVISION ")\n"); + puts(hr); + + /* Identify environment */ + printf("\nRunning on %s in environment %s\n", manifest_board, + manifest_environment); + + printf("\nHW_CODE = 0x%04x", readw(MTK_CONFG_HW_CODE)); + + /* Set up loader communications */ + sercomm_register_rx_cb(SC_DLCI_LOADER, &cmd_handler); + + /* Wait for events */ + + while (1) { + uart_poll(SERCOMM_UART_NR); + } + +} + +static void cmd_handler(uint8_t dlci, struct msgb *msg) +{ + if (msg->data_len < 1) { + return; + } + + uint8_t command = msgb_get_u8(msg); + + int res; + + flash_lock_t lock; + + void *data; + + uint8_t chip; + uint8_t nbytes; + uint16_t crc, mycrc; + uint32_t address; + + struct msgb *reply = sercomm_alloc_msgb(256); // XXX + + if (!reply) { + printf("Failed to allocate reply buffer!\n"); + goto out; + } + + switch (command) { + + case LOADER_PING: + loader_send_simple(reply, dlci, LOADER_PING); + break; + + case LOADER_RESET: + loader_send_simple(reply, dlci, LOADER_RESET); + device_reset(); + break; + + case LOADER_POWEROFF: + loader_send_simple(reply, dlci, LOADER_POWEROFF); + device_poweroff(); + break; + + case LOADER_ENTER_ROM_LOADER: + loader_send_simple(reply, dlci, LOADER_ENTER_ROM_LOADER); + device_enter_loader(1); + break; + + case LOADER_ENTER_FLASH_LOADER: + loader_send_simple(reply, dlci, LOADER_ENTER_FLASH_LOADER); + device_enter_loader(0); + break; + + case LOADER_MEM_READ: + + nbytes = msgb_get_u8(msg); + address = msgb_get_u32(msg); + + crc = crc16(0, (void *)address, nbytes); + + msgb_put_u8(reply, LOADER_MEM_READ); + msgb_put_u8(reply, nbytes); + msgb_put_u16(reply, crc); + msgb_put_u32(reply, address); + + memcpy(msgb_put(reply, nbytes), (void *)address, nbytes); + + sercomm_sendmsg(dlci, reply); + + break; + + case LOADER_MEM_WRITE: + + nbytes = msgb_get_u8(msg); + crc = msgb_get_u16(msg); + address = msgb_get_u32(msg); + + data = msgb_get(msg, nbytes); + + mycrc = crc16(0, data, nbytes); + + if (mycrc == crc) { + memcpy((void *)address, data, nbytes); + } + + msgb_put_u8(reply, LOADER_MEM_WRITE); + msgb_put_u8(reply, nbytes); + msgb_put_u16(reply, mycrc); + msgb_put_u32(reply, address); + + sercomm_sendmsg(dlci, reply); + + break; + + case LOADER_JUMP: + + address = msgb_get_u32(msg); + + msgb_put_u8(reply, LOADER_JUMP); + msgb_put_u32(reply, address); + + sercomm_sendmsg(dlci, reply); + + device_jump((void *)address); + + break; + + case LOADER_FLASH_INFO: + + msgb_put_u8(reply, LOADER_FLASH_INFO); + msgb_put_u8(reply, 1); // nchips + + // chip 1 + msgb_put_u32(reply, the_flash.f_base); + msgb_put_u32(reply, the_flash.f_size); + msgb_put_u8(reply, the_flash.f_nregions); + + unsigned i; + for (i = 0; i < the_flash.f_nregions; i++) { + msgb_put_u32(reply, the_flash.f_regions[i].fr_bnum); + msgb_put_u32(reply, the_flash.f_regions[i].fr_bsize); + } + + sercomm_sendmsg(dlci, reply); + + break; + + case LOADER_FLASH_ERASE: + case LOADER_FLASH_UNLOCK: + case LOADER_FLASH_LOCK: + case LOADER_FLASH_LOCKDOWN: + + chip = msgb_get_u8(msg); + address = msgb_get_u32(msg); + + if (command == LOADER_FLASH_ERASE) { + res = flash_block_erase(&the_flash, address); + } + if (command == LOADER_FLASH_UNLOCK) { + res = flash_block_unlock(&the_flash, address); + } + if (command == LOADER_FLASH_LOCK) { + res = flash_block_lock(&the_flash, address); + } + if (command == LOADER_FLASH_LOCKDOWN) { + res = flash_block_lockdown(&the_flash, address); + } + + msgb_put_u8(reply, command); + msgb_put_u8(reply, chip); + msgb_put_u32(reply, address); + msgb_put_u32(reply, (res != 0)); + + sercomm_sendmsg(dlci, reply); + + break; + + case LOADER_FLASH_GETLOCK: + + chip = msgb_get_u8(msg); + address = msgb_get_u32(msg); + + lock = flash_block_getlock(&the_flash, address); + + msgb_put_u8(reply, command); + msgb_put_u8(reply, chip); + msgb_put_u32(reply, address); + + switch (lock) { + case FLASH_UNLOCKED: + msgb_put_u32(reply, LOADER_FLASH_UNLOCKED); + break; + case FLASH_LOCKED: + msgb_put_u32(reply, LOADER_FLASH_LOCKED); + break; + case FLASH_LOCKED_DOWN: + msgb_put_u32(reply, LOADER_FLASH_LOCKED_DOWN); + break; + default: + msgb_put_u32(reply, 0xFFFFFFFF); + break; + } + + sercomm_sendmsg(dlci, reply); + + break; + + case LOADER_FLASH_PROGRAM: + + nbytes = msgb_get_u8(msg); + crc = msgb_get_u16(msg); + msgb_get_u8(msg); // XXX align + chip = msgb_get_u8(msg); + address = msgb_get_u32(msg); + + data = msgb_get(msg, nbytes); + + mycrc = crc16(0, data, nbytes); + + if (mycrc == crc) { + res = flash_program(&the_flash, address, data, nbytes); + } + + msgb_put_u8(reply, LOADER_FLASH_PROGRAM); + msgb_put_u8(reply, nbytes); + msgb_put_u16(reply, mycrc); + msgb_put_u8(reply, 0); // XXX align + msgb_put_u8(reply, chip); + msgb_put_u32(reply, address); + + msgb_put_u32(reply, (uint32_t) res); // XXX + + sercomm_sendmsg(dlci, reply); + + break; + + default: + printf("unknown command %d\n", command); + + msgb_free(reply); + + break; + } + + out: + + msgb_free(msg); +} diff --git a/src/target/firmware/board/mediatek/macros.S b/src/target/firmware/board/mediatek/macros.S new file mode 100644 index 0000000..14ee6e6 --- /dev/null +++ b/src/target/firmware/board/mediatek/macros.S @@ -0,0 +1,76 @@ + +.macro clear_bss + mov r0, #0 + ldr r1, =__bss_start + ldr r2, =__bss_end +loop_bss: + cmp r1, r2 + strlo r0, [r1], #4 + blo loop_bss +.endm + +.macro copy_data + ldr r0, =__data_start + ldr r1, =_data_start + ldr r2, =__data_end + cmp r0, r2 + beq done_data +loop_data: + ldrb r4, [r0], #1 + strb r4, [r1], #1 + cmp r0, r2 + bne loop_data +done_data: +.endm + +.macro copy_ramtext + ldr r0, =__ramtext_start + ldr r1, =_ramtext_start + ldr r2, =__ramtext_end + cmp r0, r2 + beq done_ramtext +loop_ramtext: + ldrb r4, [r0], #1 + strb r4, [r1], #1 + cmp r0, r2 + bne loop_ramtext +done_ramtext: +.endm + + .EQU ARM_MODE_FIQ, 0x11 + .EQU ARM_MODE_IRQ, 0x12 + .EQU ARM_MODE_SVC, 0x13 + + .EQU I_BIT, 0x80 + .EQU F_BIT, 0x40 + +#define TOP_OF_RAM 0x4000a000 +#define FIQ_STACK_SIZE 1024 +#define IRQ_STACK_SIZE 1024 + +.macro init_stacks + /* initialize stacks, starting at TOP_OF_RAM */ + ldr r0, =TOP_OF_RAM + + /* initialize FIQ stack */ + msr CPSR_c, #ARM_MODE_FIQ | I_BIT | F_BIT + mov r13, r0 + sub r0, r0, #FIQ_STACK_SIZE + + /* initialize IRQ stack */ + msr CPSR_c, #ARM_MODE_IRQ | I_BIT | F_BIT + mov r13, r0 + sub r0, r0, #IRQ_STACK_SIZE + + /* initialize supervisor stack */ + msr CPSR_c, #ARM_MODE_SVC | I_BIT | F_BIT + mov r13, r0 +.endm + +.macro call_ctors + /* call constructor functions */ + ldr r0, =_ctor_start + ldr r1, =_ctor_end + bl do_global_ctors +.endm + diff --git a/src/target/firmware/board/mediatek/ram.lds b/src/target/firmware/board/mediatek/ram.lds new file mode 100644 index 0000000..465c0ba --- /dev/null +++ b/src/target/firmware/board/mediatek/ram.lds @@ -0,0 +1,112 @@ +/* + * Linker script for running from internal SRAM on MTK phones + * + * This script is tailored specifically to the requirements imposed + * on us by the Mediatek bootloader. + * + */ +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +MEMORY +{ + /* mtk-loaded binary: our text, initialized data */ + LRAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00005000 + /* mtk-loaded binary: our unitialized data, stacks, heap */ + IRAM (rw) : ORIGIN = 0x40005000, LENGTH = 0x00005000 +} +SECTIONS +{ + . = 0x40000000; + + /* romloader data section, contains passthru interrupt vectors */ + .mtk.loader (NOLOAD) : { . = 0x1400; } > LRAM + + /* initialization code */ + . = ALIGN(4); + .text.start : { + PROVIDE(_start = .); + KEEP(*(.text.start)) + *(.text.start) + } > LRAM + + /* code */ + . = ALIGN(4); + .text (LOADADDR(.text.start) + SIZEOF(.text.start)) : + AT (LOADADDR(.text.start) + SIZEOF(.text.start)) { + /* regular code */ + *(.text*) + /* always-in-ram code */ + *(.ramtext*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + . = ALIGN(4); + } > LRAM + PROVIDE(_text_start = LOADADDR(.text)); + PROVIDE(_text_end = LOADADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > LRAM + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > LRAM + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + . = ALIGN(4); + .rodata : { + *(.rodata*) + } > LRAM + PROVIDE(_rodata_start = LOADADDR(.rodata)); + PROVIDE(_rodata_end = LOADADDR(.rodata) + SIZEOF(.rodata)); + + /* initialized data */ + . = ALIGN(4); + .data : { + *(.data) + } > LRAM + PROVIDE(_data_start = LOADADDR(.data)); + PROVIDE(_data_end = LOADADDR(.data) + SIZEOF(.data)); + + /* pic offset tables */ + . = ALIGN(4); + .got : { + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + } > LRAM + PROVIDE(_got_start = LOADADDR(.got)); + PROVIDE(_got_end = LOADADDR(.got) + SIZEOF(.got)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + __bss_start = .; + *(.bss) + } > IRAM + . = ALIGN(4); + __bss_end = .; + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} diff --git a/src/target/firmware/board/mediatek/start.ram.S b/src/target/firmware/board/mediatek/start.ram.S new file mode 100644 index 0000000..c8f242c --- /dev/null +++ b/src/target/firmware/board/mediatek/start.ram.S @@ -0,0 +1,26 @@ + +.section .text.start + +#include "macros.S" + +.globl _start +_start: + /* clear bss section */ + clear_bss + + /* initialize all stacks */ + init_stacks + + /* call constructors */ + call_ctors + + /* jump to main */ + ldr pc, _jump_main + + /* endless loop at end of program */ +_loop: + b _loop + b _start + +_jump_main: + .word main diff --git a/src/target/firmware/board/mediatek/uart.c b/src/target/firmware/board/mediatek/uart.c new file mode 100644 index 0000000..ff82245 --- /dev/null +++ b/src/target/firmware/board/mediatek/uart.c @@ -0,0 +1,426 @@ +/* MediaTek MT62xx internal UART Driver + * + * based on the Calypso driver, so there might be some cruft from it left... + * + * (C) 2010 by Harald Welte + * (C) 2010 by Ingo Albrecht + * (C) 2010 by Steve Markgraf + * (C) 2011 by Wolfram Sang + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include + +/* MT622x */ +#if 0 +#define BASE_ADDR_UART1 0x80130000 +#define BASE_ADDR_UART2 0x80180000 +#define BASE_ADDR_UART3 0x801b0000 +#endif + +/* MT 6235 */ +#define BASE_ADDR_UART1 0x81030000 + +//TODO make UART2 and 3 work +#define UART_REG(n,m) (BASE_ADDR_UART1 + (m)) + +#define LCR7BIT 0x80 +#define LCRBFBIT 0x40 +#define MCR6BIT 0x20 +#define REG_OFFS(m) ((m) & ~(LCR7BIT|LCRBFBIT|MCR6BIT)) +/* read access LCR[7] = 0 */ +enum uart_reg { + RBR = 0x00, + IER = 0x04, + IIR = 0x08, + LCR = 0x0c, + MCR = 0x10, + LSR = 0x14, + MSR = 0x18, + SCR = 0x1c, + AUTOBAUD_EN = 0x20, + HIGHSPEED = 0x24, + SAMPLE_COUNT = 0x28, + SAMPLE_POINT = 0x2c, + AUTOBAUD_REG = 0x30, + RATE_FIX_REG = 0x34, /* undocumented */ + AUTOBAUDSAMPLE = 0x38, + GUARD = 0x3c, + ESCAPE_DAT = 0x40, + ESCAPE_EN = 0x44, + SLEEP_EN = 0x48, + VFIFO_EN = 0x4c, +/* read access LCR[7] = 1 */ + DLL = RBR, + DLH = IER, +/* read/write access LCR[7:0] = 0xbf */ + EFR = IIR | LCRBFBIT, + XON1 = MCR | LCRBFBIT, + XON2 = LSR | LCRBFBIT, + XOFF1 = MSR | LCRBFBIT, + XOFF2 = SCR | LCRBFBIT, +}; + +enum fcr_bits { + FIFO_EN = (1 << 0), + RX_FIFO_CLEAR = (1 << 1), + TX_FIFO_CLEAR = (1 << 2), + DMA_MODE = (1 << 3), +}; +#define TX_FIFO_TRIG_SHIFT 4 +#define RX_FIFO_TRIG_SHIFT 6 + +enum iir_bits { + IIR_INT_PENDING = 0x01, + IIR_INT_TYPE = 0x3E, + IIR_INT_TYPE_RX_STATUS_ERROR = 0x06, + IIR_INT_TYPE_RX_TIMEOUT = 0x0C, + IIR_INT_TYPE_RBR = 0x04, + IIR_INT_TYPE_THR = 0x02, + IIR_INT_TYPE_MSR = 0x00, + IIR_INT_TYPE_XOFF = 0x10, + IIR_INT_TYPE_FLOW = 0x20, + IIR_FCR0_MIRROR = 0xC0, +}; + + +/* enable or disable the divisor latch for access to DLL, DLH */ +static void uart_set_lcr7bit(int uart, int on) +{ + uint8_t reg; + + reg = readb(UART_REG(uart, LCR)); + if (on) + reg |= (1 << 7); + else + reg &= ~(1 << 7); + writeb(reg, UART_REG(uart, LCR)); +} + +static uint8_t old_lcr; +static void uart_set_lcr_bf(int uart, int on) +{ + if (on) { + old_lcr = readb(UART_REG(uart, LCR)); + writeb(0xBF, UART_REG(uart, LCR)); + } else { + writeb(old_lcr, UART_REG(uart, LCR)); + } +} + +/* Enable or disable the TCR_TLR latch bit in MCR[6] */ +static void uart_set_mcr6bit(int uart, int on) +{ + uint8_t mcr; + /* we assume EFR[4] is always set to 1 */ + mcr = readb(UART_REG(uart, MCR)); + if (on) + mcr |= (1 << 6); + else + mcr &= ~(1 << 6); + writeb(mcr, UART_REG(uart, MCR)); +} + +static void uart_reg_write(int uart, enum uart_reg reg, uint8_t val) +{ + if (reg & LCRBFBIT) + uart_set_lcr_bf(uart, 1); + else if (reg & LCR7BIT) + uart_set_lcr7bit(uart, 1); + else if (reg & MCR6BIT) + uart_set_mcr6bit(uart, 1); + + writeb(val, UART_REG(uart, REG_OFFS(reg))); + + if (reg & LCRBFBIT) + uart_set_lcr_bf(uart, 0); + else if (reg & LCR7BIT) + uart_set_lcr7bit(uart, 0); + else if (reg & MCR6BIT) + uart_set_mcr6bit(uart, 0); +} + +/* read from a UART register, applying any required latch bits */ +static uint8_t uart_reg_read(int uart, enum uart_reg reg) +{ + uint8_t ret; + + if (reg & LCRBFBIT) + uart_set_lcr_bf(uart, 1); + else if (reg & LCR7BIT) + uart_set_lcr7bit(uart, 1); + else if (reg & MCR6BIT) + uart_set_mcr6bit(uart, 1); + + ret = readb(UART_REG(uart, REG_OFFS(reg))); + + if (reg & LCRBFBIT) + uart_set_lcr_bf(uart, 0); + else if (reg & LCR7BIT) + uart_set_lcr7bit(uart, 0); + else if (reg & MCR6BIT) + uart_set_mcr6bit(uart, 0); + + return ret; +} + +static void uart_irq_handler_cons(__unused int irqnr) +{ + const uint8_t uart = CONS_UART_NR; + uint8_t iir; + + //uart_putchar_nb(uart, 'U'); + + iir = uart_reg_read(uart, IIR); + if (iir & IIR_INT_PENDING) + return; + + switch (iir & IIR_INT_TYPE) { + case IIR_INT_TYPE_RBR: + break; + case IIR_INT_TYPE_THR: + if (cons_rb_flush() == 1) { + /* everything was flushed, disable RBR IRQ */ + uint8_t ier = uart_reg_read(uart, IER); + ier &= ~(1 << 1); + uart_reg_write(uart, IER, ier); + } + break; + case IIR_INT_TYPE_MSR: + break; + case IIR_INT_TYPE_RX_STATUS_ERROR: + break; + case IIR_INT_TYPE_RX_TIMEOUT: + break; + case IIR_INT_TYPE_XOFF: + break; + } +} + +static void uart_irq_handler_sercomm(__unused int irqnr) +{ + const uint8_t uart = SERCOMM_UART_NR; + uint8_t iir, ch; + + //uart_putchar_nb(uart, 'U'); + + iir = uart_reg_read(uart, IIR); + if (iir & IIR_INT_PENDING) + return; + + switch (iir & IIR_INT_TYPE) { + case IIR_INT_TYPE_RX_TIMEOUT: + case IIR_INT_TYPE_RBR: + /* as long as we have rx data available */ + while (uart_getchar_nb(uart, &ch)) { + if (sercomm_drv_rx_char(ch) < 0) { + /* sercomm cannot receive more data right now */ + uart_irq_enable(uart, UART_IRQ_RX_CHAR, 0); + } + } + break; + case IIR_INT_TYPE_THR: + /* as long as we have space in the FIFO */ + while (!uart_tx_busy(uart)) { + /* get a byte from sercomm */ + if (!sercomm_drv_pull(&ch)) { + /* no more bytes in sercomm, stop TX interrupts */ + uart_irq_enable(uart, UART_IRQ_TX_EMPTY, 0); + break; + } + /* write the byte into the TX FIFO */ + uart_putchar_nb(uart, ch); + } + break; + case IIR_INT_TYPE_MSR: + printf("UART IRQ MSR\n"); + break; + case IIR_INT_TYPE_RX_STATUS_ERROR: + printf("UART IRQ RX_SE\n"); + break; + case IIR_INT_TYPE_XOFF: + printf("UART IRQXOFF\n"); + break; + } +} + +void uart_init(uint8_t uart, __unused uint8_t interrupts) +{ + /* no interrupts, only polling so far */ + + uart_reg_write(uart, IER, 0x00); + if (uart == CONS_UART_NR) { + cons_init(); + } else { + sercomm_init(); + uart_irq_enable(uart, UART_IRQ_RX_CHAR, 1); + } + + uart_reg_write(uart, AUTOBAUD_EN, 0x00); /* disable AUTOBAUD */ + uart_reg_write(uart, EFR, 0x10); /* Enhanced Features Register */ + + /* no XON/XOFF flow control, ENHANCED_EN, no auto-RTS/CTS */ + uart_reg_write(uart, EFR, (1 << 4)); + /* enable Tx/Rx FIFO, Tx trigger at 56 spaces, Rx trigger at 60 chars */ + //FIXME check those FIFO settings + uart_reg_write(uart, IIR, FIFO_EN | RX_FIFO_CLEAR | TX_FIFO_CLEAR | + (3 << TX_FIFO_TRIG_SHIFT) | (1 << RX_FIFO_TRIG_SHIFT)); + + /* RBR interrupt only when TX FIFO and TX shift register are empty */ + uart_reg_write(uart, SCR, (1 << 0));// | (1 << 3)); + + /* 8 bit, 1 stop bit, no parity, no break */ + uart_reg_write(uart, LCR, 0x03); + + uart_set_lcr7bit(uart, 0); +} + +void uart_poll(uint8_t uart) { + if(uart == CONS_UART_NR) { + uart_irq_handler_cons(0); + } else { + uart_irq_handler_sercomm(0); + } +} + +void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on) +{ + uint8_t ier = uart_reg_read(uart, IER); + uint8_t mask = 0; + + switch (irq) { + case UART_IRQ_TX_EMPTY: + mask = (1 << 1); + break; + case UART_IRQ_RX_CHAR: + mask = (1 << 0); + break; + } + + if (on) + ier |= mask; + else + ier &= ~mask; + + uart_reg_write(uart, IER, ier); +} + + +void uart_putchar_wait(uint8_t uart, int c) +{ + /* wait while TX FIFO indicates full */ + while (~readb(UART_REG(uart, LSR)) & 0x20) { } + + /* put character in TX FIFO */ + writeb(c, UART_REG(uart, RBR)); +} + +int uart_putchar_nb(uint8_t uart, int c) +{ + /* if TX FIFO indicates full, abort */ + if (~readb(UART_REG(uart, LSR)) & 0x20) + return 0; + + writeb(c, UART_REG(uart, RBR)); + return 1; +} + +int uart_getchar_nb(uint8_t uart, uint8_t *ch) +{ + uint8_t lsr; + + lsr = readb(UART_REG(uart, LSR)); + + /* something strange happened */ + if (lsr & 0x02) + printf("LSR RX_OE\n"); + if (lsr & 0x04) + printf("LSR RX_PE\n"); + if (lsr & 0x08) + printf("LSR RX_FE\n"); + if (lsr & 0x10) + printf("LSR RX_BI\n"); + if (lsr & 0x80) + printf("LSR RX_FIFO_STS\n"); + + /* is the Rx FIFO empty? */ + if (!(lsr & 0x01)) + return 0; + + *ch = readb(UART_REG(uart, RBR)); + //printf("getchar_nb(%u) = %02x\n", uart, *ch); + return 1; +} + +int uart_tx_busy(uint8_t uart) +{ + /* Check THRE bit (LSR[5]) to see if FIFO is full */ + if (~readb(UART_REG(uart, LSR)) & 0x20) + return 1; + return 0; +} + +#if 0 +/* 26MHz clock input (used when no PLL initialized directly after poweron) */ +static const uint16_t divider[] = { + [UART_38400] = 42, + [UART_57600] = 28, + [UART_115200] = 14, + [UART_230400] = 7, + [UART_460800] = 14, /* would need UART_REG(HIGHSPEED) = 1 or 2 */ + [UART_921600] = 7, /* would need UART_REG(HIGHSPEED) = 2 */ +}; +#endif + +/* 52MHz clock input (after PLL init) */ +static const uint16_t divider[] = { + [UART_38400] = 85, + [UART_57600] = 56, + [UART_115200] = 28, + [UART_230400] = 14, + [UART_460800] = 7, + [UART_921600] = 7, /* would need UART_REG(HIGHSPEED) = 1 */ +}; + +int uart_baudrate(uint8_t uart, enum uart_baudrate bdrt) +{ + uint16_t div; + + if (bdrt > ARRAY_SIZE(divider)) + return -1; + + div = divider[bdrt]; + uart_set_lcr7bit(uart, 1); + writeb(div & 0xff, UART_REG(uart, DLL)); + writeb(div >> 8, UART_REG(uart, DLH)); + uart_set_lcr7bit(uart, 0); + + return 0; +} diff --git a/src/target/firmware/board/mt62xx/init.c b/src/target/firmware/board/mt62xx/init.c new file mode 100644 index 0000000..3f68375 --- /dev/null +++ b/src/target/firmware/board/mt62xx/init.c @@ -0,0 +1,139 @@ +/* Initialization for the MT62xx Basebands */ + +/* (C) 2010 by Steve Markgraf + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include + +#include +#include +#include + +void pll_init(void) +{ + /* Power on PLL */ + writew(0, MTK_PLL_PDN_CON); + writew(PLL_CLKSQ_DIV2_DSP | PLL_CLKSQ_DIV2_MCU, MTK_PLL_CLK_CON); + + writew(PLL_RST, MTK_PLL_PLL); + writew(0, MTK_PLL_PLL); + delay_ms(1); + + /* Turn on PLL for MCU, DSP and USB */ + writew(PLL_MPLLSEL_PLL | PLL_DPLLSEL | PLL_UPLLSEL, MTK_PLL_PLL); + + /* + * Setup MCU clock register: + * ARMCLK = 208MHz, AHBx4CLK = 52MHz, AHBx8CLK = 104MHz + * we have to write to the read-only part (EMICLK) as well, otherwise + * the EMI won't work! (datasheet lies) + */ + writew(7 << MCUCLK_CON_AHBX8CLK_SHIFT | + 3 << MCUCLK_CON_AHBX4CLK_SHIFT | + 15 << MCUCLK_CON_ARMCLK_SHIFT | + 7 << MCUCLK_CON_EMICLK_SHIFT, + MTK_CONFG_MCUCLK_CON); +} + +void memory_init(void) +{ + int i; + + /* Initialization for Hynix RAM */ + + /* Configure DRAM controller */ + writel(0x0001000e, MTK_EMI_GEND); + writel(0x00088a0a, MTK_EMI_GENA); + writel(0x00000280, MTK_EMI_GENB); + writel(0x52945294, MTK_EMI_GENC); + writel(0x1c016605, MTK_EMI_CONL); + writel(0x00002828, MTK_EMI_CONM); + writel(0x02334000, MTK_EMI_CONI); + writel(0x16c12212, MTK_EMI_CONJ); + writel(0x032d0000, MTK_EMI_CONK); + + for (i = 0; i < 5; ++i) { + /* Setup five single bits, one by one for DRAM init */ + writel((1 << (24 + i)) | (0x400013), MTK_EMI_CONN); + delay_ms(1); + writel(0x400013, MTK_EMI_CONN); + delay_ms(1); + } + +#if 0 + /* Initialization for Toshiba RAM */ + + /* Configure DRAM controller */ + writel(0x0001000E, MTK_EMI_GEND); + writel(0x00088E3A, MTK_EMI_GENA); + writel(0x000000C0, MTK_EMI_GENB); + writel(0x18C618C6, MTK_EMI_GENC); + writel(0x18007505, MTK_EMI_CONL); + writel(0x00002828, MTK_EMI_CONM); + writel(0x00332000, MTK_EMI_CONI); + writel(0x3CD24431, MTK_EMI_CONJ); + writel(0x02000000, MTK_EMI_CONK); + + for (i = 0; i < 5; ++i) { + /* Setup five single bits, one by one for DRAM init */ + writel((1 << (24 + i)) | (0x500013), MTK_EMI_CONN); + delay_ms(1); + writel(0x500013, MTK_EMI_CONN); + delay_ms(1); + } + +#endif +} + +void board_init(void) +{ + /* powerup the baseband */ + writew(POWERKEY1_MAGIC, MTK_RTC_POWERKEY1); + writew(POWERKEY2_MAGIC, MTK_RTC_POWERKEY2); + writew(BBPU_MAGIC | RTC_BBPU_WRITE_EN | + RTC_BBPU_BBPU | RTC_BBPU_AUTO, + MTK_RTC_BBPU); + writew(1, MTK_RTC_WRTGR); + + /* disable watchdog timer */ + writew(WDT_MODE_KEY, MTK_RGU_WDT_MODE); + + pll_init(); + memory_init(); + + /* Initialize UART without interrupts */ + uart_init(SERCOMM_UART_NR, 0); + uart_baudrate(SERCOMM_UART_NR, UART_115200); +} diff --git a/src/target/firmware/include/mtk/emi.h b/src/target/firmware/include/mtk/emi.h new file mode 100644 index 0000000..1818499 --- /dev/null +++ b/src/target/firmware/include/mtk/emi.h @@ -0,0 +1,42 @@ +/* + * (C) 2010 by Tieto + * Marcin Mielczarczyk + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#ifndef __MTK_EMI_H_ +#define __MTK_EMI_H_ + +/* External Memory Interface register definitions */ +#define MTK_EMI_CONA (MTK_EMI_BASE + 0x00) +#define MTK_EMI_CONB (MTK_EMI_BASE + 0x08) +#define MTK_EMI_CONC (MTK_EMI_BASE + 0x10) +#define MTK_EMI_COND (MTK_EMI_BASE + 0x18) +#define MTK_EMI_CONI (MTK_EMI_BASE + 0x40) +#define MTK_EMI_CONJ (MTK_EMI_BASE + 0x48) +#define MTK_EMI_CONK (MTK_EMI_BASE + 0x50) +#define MTK_EMI_CONL (MTK_EMI_BASE + 0x58) +#define MTK_EMI_CONM (MTK_EMI_BASE + 0x60) +#define MTK_EMI_CONN (MTK_EMI_BASE + 0x68) +#define MTK_EMI_GENA (MTK_EMI_BASE + 0x70) +#define MTK_EMI_GENB (MTK_EMI_BASE + 0x78) +#define MTK_EMI_GENC (MTK_EMI_BASE + 0x80) +#define MTK_EMI_GEND (MTK_EMI_BASE + 0x88) + +#endif diff --git a/src/target/firmware/include/mtk/mt6235.h b/src/target/firmware/include/mtk/mt6235.h new file mode 100644 index 0000000..fb9d368 --- /dev/null +++ b/src/target/firmware/include/mtk/mt6235.h @@ -0,0 +1,74 @@ +/* + * (C) 2010 by Tieto + * Marcin Mielczarczyk + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#ifndef __MT6235_H +#define __MT6235_H + +/* Peripheral base addresses */ +#define MTK_EFUSE_BASE 0x80000000 +#define MTK_CONFG_BASE 0x80010000 +#define MTK_GPIO_BASE 0x80020000 +#define MTK_RGU_BASE 0x80030000 +#define MTK_EMI_BASE 0x81000000 +#define MTK_CIRQ_BASE 0x81010000 +#define MTK_DMA_BASE 0x81020000 +#define MTK_UART1_BASE 0x81030000 +#define MTK_UART2_BASE 0x81040000 +#define MTK_UART3_BASE 0x81050000 +#define MTK_GPT_BASE 0x81060000 +#define MTK_KP_BASE 0x81080000 +#define MTK_PWM_BASE 0x81090000 +#define MTK_SIM_BASE 0x810A0000 +#define MTK_RTC_BASE 0x810C0000 +#define MTK_SEJ_BASE 0x810D0000 +#define MTK_BM_BASE 0x810E0000 +#define MTK_IRDA_BASE 0x810F0000 +#define MTK_I2C_BASE 0x81100000 +#define MTK_MSDC_BASE 0x81110000 +#define MTK_NFI_BASE 0x81120000 +#define MTK_MSSDC2_BASE 0x81140000 +#define MTK_TDMA_BASE 0x82000000 +#define MTK_BSI_BASE 0x82010000 +#define MTK_BPI_BASE 0x82020000 +#define MTK_AFC_BASE 0x82030000 +#define MTK_APC_BASE 0x82040000 +#define MTK_AUXADC_BASE 0x82050000 +#define MTK_DIVIDER_BASE 0x82060000 +#define MTK_FSC_BASE 0x82070000 +#define MTK_GCU_BASE 0x82080000 +#define MTK_CSD_ACC_BASE 0x82090000 +#define MTK_SHARE1_BASE 0x820A0000 +#define MTK_IRDBG1_BASE 0x820B0000 +#define MTK_SHARE2_BASE 0x820C0000 +#define MTK_IRDBG2_BASE 0x820D0000 +#define MTK_PATCH_BASE 0x820E0000 +#define MTK_AFE_BASE 0x820F0000 +#define MTK_BFE_BASE 0x82100000 +#define MTK_PLL_BASE 0x83000000 +#define MTK_ACIF_BASE 0x83010000 +#define MTK_GMC_BASE 0x84000000 +#define MTK_G2D_BASE 0x84010000 +#define MTK_GCMQ_BASE 0x84020000 +#define MTK_CAM_BASE 0x840B0000 +#define MTK_CRZ_BASE 0x840E0000 + +#endif diff --git a/src/target/firmware/include/mtk/system.h b/src/target/firmware/include/mtk/system.h new file mode 100644 index 0000000..4543029 --- /dev/null +++ b/src/target/firmware/include/mtk/system.h @@ -0,0 +1,195 @@ +/* + * (C) 2010 by Tieto + * Marcin Mielczarczyk + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#ifndef __MTK_SYSTEM_H_ +#define __MTK_SYSTEM_H_ + +/* + * Configuration block section (Clock, Power Down, Version and Reset + */ + +/* Register definitions */ +#define MTK_CONFG_HW_VERSION (MTK_CONFG_BASE + 0x000) +#define MTK_CONFG_FW_VERSION (MTK_CONFG_BASE + 0x004) +#define MTK_CONFG_HW_CODE (MTK_CONFG_BASE + 0x008) +#define MTK_CONFG_SLEEP_CON (MTK_CONFG_BASE + 0x114) +#define MTK_CONFG_MCUCLK_CON (MTK_CONFG_BASE + 0x118) +#define MTK_CONFG_DSPCLK_CON (MTK_CONFG_BASE + 0x11C) +#define MTK_CONFG_IDN_SEL (MTK_CONFG_BASE + 0x200) +#define MTK_CONFG_PDN_CON0 (MTK_CONFG_BASE + 0x300) +#define MTK_CONFG_PDN_CON1 (MTK_CONFG_BASE + 0x304) +#define MTK_CONFG_PDN_CON2 (MTK_CONFG_BASE + 0x308) +#define MTK_CONFG_PDN_CON3 (MTK_CONFG_BASE + 0x30C) +#define MTK_CONFG_PDN_SET0 (MTK_CONFG_BASE + 0x310) +#define MTK_CONFG_PDN_SET1 (MTK_CONFG_BASE + 0x314) +#define MTK_CONFG_PDN_SET2 (MTK_CONFG_BASE + 0x318) +#define MTK_CONFG_PDN_SET3 (MTK_CONFG_BASE + 0x31C) +#define MTK_CONFG_PDN_CLR0 (MTK_CONFG_BASE + 0x320) +#define MTK_CONFG_PDN_CLR1 (MTK_CONFG_BASE + 0x324) +#define MTK_CONFG_PDN_CLR2 (MTK_CONFG_BASE + 0x328) +#define MTK_CONFG_PDN_CLR3 (MTK_CONFG_BASE + 0x32C) + +/* CONFG_MCUCLK_CON bit fields definitions */ +#define MCUCLK_CON_AHBX8CLK_SHIFT (0) +#define MCUCLK_CON_AHBX4CLK_SHIFT (4) +#define MCUCLK_CON_ARMCLK_SHIFT (8) +#define MCUCLK_CON_EMICLK_SHIFT (12) + +/* PDN_CON0 bit fields definitions */ +#define PDN_CON0_CON0_DMA (1 << 0) +#define PDN_CON0_USB (1 << 1) +#define PDN_CON0_GCU (1 << 2) +#define PDN_CON0_WAVE (1 << 3) +#define PDN_CON0_SEJ (1 << 4) +#define PDN_CON0_IR (1 << 6) +#define PDN_CON0_PWM3 (1 << 7) +#define PDN_CON0_PWM (1 << 8) +#define PDN_CON0_SIM2 (1 << 10) +#define PDN_CON0_IRDBG1 (1 << 12) +#define PDN_CON0_IRDBG2 (1 << 13) + +/* PDN_CON1 bit fields definitions */ +#define PDN_CON1_GPT (1 << 0) +#define PDN_CON1_KP (1 << 1) +#define PDN_CON1_GPIO (1 << 2) +#define PDN_CON1_UART1 (1 << 3) +#define PDN_CON1_SIM (1 << 4) +#define PDN_CON1_PWM1 (1 << 5) +#define PDN_CON1_LCD (1 << 7) +#define PDN_CON1_UART2 (1 << 8) +#define PDN_CON1_MSDC (1 << 9) +#define PDN_CON1_TP (1 << 10) +#define PDN_CON1_PWM2 (1 << 11) +#define PDN_CON1_NFI (1 << 12) +#define PDN_CON1_UART3 (1 << 14) +#define PDN_CON1_IRDA (1 << 15) + +/* PDN_CON2 bit fields definitions */ +#define PDN_CON2_TDMA (1 << 0) +#define PDN_CON2_RTC (1 << 1) +#define PDN_CON2_BSI (1 << 2) +#define PDN_CON2_BPI (1 << 3) +#define PDN_CON2_AFC (1 << 4) +#define PDN_CON2_APC (1 << 5) + +/* + * Reset Generation Unit block section + */ +#define MTK_RGU_WDT_MODE (MTK_RGU_BASE + 0x00) +#define MTK_RGU_WDT_LENGTH (MTK_RGU_BASE + 0x04) +#define MTK_RGU_WDT_RESTART (MTK_RGU_BASE + 0x08) +#define MTK_RGU_WDT_STA (MTK_RGU_BASE + 0x0C) +#define MTK_RGU_SW_PERIPH_RSTN (MTK_RGU_BASE + 0x10) +#define MTK_RGU_SW_DSP_RSTN (MTK_RGU_BASE + 0x14) +#define MTK_RGU_WDT_RSTINTERVAL (MTK_RGU_BASE + 0x18) +#define MTK_RGU_WDT_SWRST (MTK_RGU_BASE + 0x1C) + +#define WDT_MODE_KEY 0x2200 +#define WDT_LENGTH_KEY 0x0008 +#define WDT_RESTART_KEY 0x1971 +#define SW_PERIPH_RSTN_KEY 0x0037 +#define WDT_SWRST_KEY 0x1209 + +/* + * RTC block section + */ + +/* RTC registers definition */ +#define MTK_RTC_BBPU (MTK_RTC_BASE + 0x00) +#define MTK_RTC_IRQ_STA (MTK_RTC_BASE + 0x04) +#define MTK_RTC_IRQ_EN (MTK_RTC_BASE + 0x08) +#define MTK_RTC_CII_EN (MTK_RTC_BASE + 0x0C) +#define MTK_RTC_AL_MASK (MTK_RTC_BASE + 0x10) +#define MTK_RTC_TC_SEC (MTK_RTC_BASE + 0x14) +#define MTK_RTC_TC_MIN (MTK_RTC_BASE + 0x18) +#define MTK_RTC_TC_HOU (MTK_RTC_BASE + 0x1C) +#define MTK_RTC_TC_DOM (MTK_RTC_BASE + 0x20) +#define MTK_RTC_TC_DOW (MTK_RTC_BASE + 0x24) +#define MTK_RTC_TC_MTH (MTK_RTC_BASE + 0x28) +#define MTK_RTC_TC_YEA (MTK_RTC_BASE + 0x2C) +#define MTK_RTC_AL_SEC (MTK_RTC_BASE + 0x30) +#define MTK_RTC_AL_MIN (MTK_RTC_BASE + 0x34) +#define MTK_RTC_AL_HOU (MTK_RTC_BASE + 0x38) +#define MTK_RTC_AL_DOM (MTK_RTC_BASE + 0x3C) +#define MTK_RTC_AL_DOW (MTK_RTC_BASE + 0x40) +#define MTK_RTC_AL_MTH (MTK_RTC_BASE + 0x44) +#define MTK_RTC_AL_YEA (MTK_RTC_BASE + 0x48) +#define MTK_RTC_XOSCCALI (MTK_RTC_BASE + 0x4C) +#define MTK_RTC_POWERKEY1 (MTK_RTC_BASE + 0x50) +#define MTK_RTC_POWERKEY2 (MTK_RTC_BASE + 0x54) +#define MTK_RTC_PDN1 (MTK_RTC_BASE + 0x58) +#define MTK_RTC_PDN2 (MTK_RTC_BASE + 0x5C) +#define MTK_RTC_SPAR1 (MTK_RTC_BASE + 0x64) +#define MTK_RTC_DIFF (MTK_RTC_BASE + 0x6C) +#define MTK_RTC_CALI (MTK_RTC_BASE + 0x70) +#define MTK_RTC_WRTGR (MTK_RTC_BASE + 0x74) + +#define POWERKEY1_MAGIC 0xA357 +#define POWERKEY2_MAGIC 0x67D2 + +/* RTC_BBPU bit fields definitions */ +#define RTC_BBPU_PWREN (1 << 0) +#define RTC_BBPU_WRITE_EN (1 << 1) +#define RTC_BBPU_BBPU (1 << 2) +#define RTC_BBPU_AUTO (1 << 3) +#define RTC_BBPU_CLRPKY (1 << 4) +#define RTC_BBPU_RELOAD (1 << 5) +#define RTC_BBPU_CBUSY (1 << 6) +#define RTC_BBPU_DBING (1 << 7) +#define RTC_BBPU_KEY_BBPU (1 << 8) + +/* RTC_BBPU write is only acceptable when KEY_BBPU=0x43 */ +#define BBPU_MAGIC 0x4300 + +/* + * PLL block section + */ + +/* PLL registers definition */ +#define MTK_PLL_PLL (MTK_PLL_BASE + 0x00) +#define MTK_PLL_PLL2 (MTK_PLL_BASE + 0x04) +#define MTK_PLL_CLK_CON (MTK_PLL_BASE + 0x18) +#define MTK_PLL_PDN_CON (MTK_PLL_BASE + 0x1C) + +/* MTK_PLL_PLL bit fields definitions */ +#define PLL_PLLVCOSEL (0 << 0) +#define PLL_MPLLSEL_SYSCLK (1 << 3) +#define PLL_MPLLSEL_PLL (2 << 3) +#define PLL_DPLLSEL (1 << 5) +#define PLL_UPLLSEL (1 << 6) +#define PLL_RST (1 << 7) +#define PLL_CALI (1 << 8) + +/* MTK_PLL_CLK_CON bit fields definitions */ +#define PLL_CLKSQ_DIV2_DSP (1 << 0) +#define PLL_CLKSQ_DIV2_MCU (1 << 1) +#define PLL_CLKSQ_PLD (1 << 2) +#define PLL_SRCCLK (1 << 7) +#define PLL_CLKSQ_TEST (1 << 15) + +/* MTK_PLL_PDN_CON bit fields definitions */ +#define PLL_PDN_CON_CLKSQ (1 << 11) +#define PLL_PDN_CON_MCU_DIV2 (1 << 12) +#define PLL_PDN_CON_PLL (1 << 13) +#define PLL_PDN_CON_DSP_DIV2 (1 << 15) + +#endif -- 1.7.2.5 From laforge at gnumonks.org Thu May 5 07:53:41 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 5 May 2011 09:53:41 +0200 Subject: [PATCH 0/5] merge mtk-loader to master In-Reply-To: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> References: <1304542697-5397-1-git-send-email-wolfram@the-dreams.de> Message-ID: <20110505075340.GA2911@prithivi.gnumonks.org> Thanks Wolfram, I've applied your entire patch series. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vanhell at gmail.com Thu May 5 10:57:21 2011 From: vanhell at gmail.com (ArMaND VanHell) Date: Thu, 5 May 2011 12:57:21 +0200 Subject: Questions regarding testing branch Message-ID: Some questions about Sylvain testing branch: why is not merged SIMreader into master branch? is planned for mobile aplication to support SMS (sending/receiving)? Thank you, ArMaND VanHell From screaming-pain at libero.it Thu May 5 14:28:34 2011 From: screaming-pain at libero.it (screaming-pain at libero.it) Date: Thu, 5 May 2011 16:28:34 +0200 (CEST) Subject: lost dump ?!?!? Message-ID: <28101624.791831304605714320.JavaMail.defaultUser@defaultHost> Hi list, I know I am very slow in understanding osmocom-bb, anyway this is just a quick question. Is it possible that some of the gsmtap messages are getting lost? For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the 'mobile' application log but there aren't the corresponding messages in the wireshark capture, though this does not always happen, I mean I had captures of location updates other times, this is why I am wondering if they are getting lost and what it does depend on. for what I understood the gsmtap functions utilities are in gsmtap_util.c and the one to send the messages on the socket is called by l1ctl.c am I right? Can you help me understanding why I cannot see all the messages? thank you in advance Loretta From vamposdecampos at gmail.com Fri May 6 06:35:50 2011 From: vamposdecampos at gmail.com (Alex Badea) Date: Fri, 6 May 2011 09:35:50 +0300 Subject: lost dump ?!?!? In-Reply-To: <28101624.791831304605714320.JavaMail.defaultUser@defaultHost> References: <28101624.791831304605714320.JavaMail.defaultUser@defaultHost> Message-ID: On Thu, May 5, 2011 at 5:28 PM, screaming-pain at libero.it wrote: > Hi list, > > I know I am very slow in understanding osmocom-bb, anyway this is just a quick > question. > Is it possible that some of the gsmtap messages are getting lost? > For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the > 'mobile' application log but there aren't the corresponding messages in the > wireshark capture, > though this does not always happen, I mean I had captures of location updates > other times, this is why I am wondering if they are getting lost and what it > does depend on. > for what I understood the gsmtap functions utilities are in gsmtap_util.c and > the one to send the messages on the socket is called by l1ctl.c am I right? > Can you help me understanding why I cannot see all the messages? > > thank you in advance > Loretta Hi, I've had this happen to me when I wasn't receiving the gsmtap packets. Specifically, I had the gsmtap packets sent over the network (i.e., non-localhost). There was no UDP listener on the receiving end, such that ICMP port-unreachable replies were being sent back. It would appear that this causes the sender's kernel to snub some of the outgoing packets. I don't know if the same happens on localhost. If this is your case, you can try "iptables -I INPUT -p udp -d 4729 -j DROP", or something like "nc -l -u 4729 > /dev/null". Cheers, Alex From laforge at gnumonks.org Fri May 6 08:52:00 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 6 May 2011 10:52:00 +0200 Subject: lost dump ?!?!? In-Reply-To: References: <28101624.791831304605714320.JavaMail.defaultUser@defaultHost> Message-ID: <20110506085200.GM29049@prithivi.gnumonks.org> On Fri, May 06, 2011 at 09:35:50AM +0300, Alex Badea wrote: > Specifically, I had the gsmtap packets sent over the network (i.e., > non-localhost). There was no UDP listener on the receiving end, such > that ICMP port-unreachable replies were being sent back. It would > appear that this causes the sender's kernel to snub some of the > outgoing packets. I don't know if the same happens on localhost. it happens on localhost, too. > If this is your case, you can try "iptables -I INPUT -p udp -d 4729 -j > DROP", or something like "nc -l -u 4729 > /dev/null". The other workaround is to use "nc -l -u -p 4729 >/dev/null" to create a process that listens on UDP port 4729 and sends all packets to /dev/null. I've recently added a gsmtap_sink to libosmocore. Once we use this from our various projects like OsmocmBB, there will be no need for any of those kludges anymore. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From screaming-pain at libero.it Fri May 6 08:11:30 2011 From: screaming-pain at libero.it (screaming-pain at libero.it) Date: Fri, 6 May 2011 10:11:30 +0200 (CEST) Subject: R: Re: lost dump ?!?!? Message-ID: <13802439.1039031304669490908.JavaMail.defaultUser@defaultHost> Thanks Alex, I actually played a bit with the code and found out that exactly half of the times the write() call in the function gsmtap_fd_cb() (gsmtap_util.c) fails because of EAGAIN or EWOULDBLOCK. I implemented a retransmission in this case and this solve the problem: all the gsmtap are successfully sent and received. Though, I suspect is impacting negatively on the rest of the mobile program. Anyway I do not have a real evidence of this only the fact that after the modification I have never had a successful location update. Do you think this is plausible? am I degrading the overall performances when trying to get all the gsmtap? Can i solve this problem? Thanks Alex and list, Loretta >----Messaggio originale---- >Da: vamposdecampos at gmail.com >Data: 6-mag-2011 8.35 >A: "screaming-pain at libero.it" >Cc: >Ogg: Re: lost dump ?!?!? > >On Thu, May 5, 2011 at 5:28 PM, screaming-pain at libero.it > wrote: >> Hi list, >> >> I know I am very slow in understanding osmocom-bb, anyway this is just a quick >> question. >> Is it possible that some of the gsmtap messages are getting lost? >> For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the >> 'mobile' application log but there aren't the corresponding messages in the >> wireshark capture, >> though this does not always happen, I mean I had captures of location updates >> other times, this is why I am wondering if they are getting lost and what it >> does depend on. >> for what I understood the gsmtap functions utilities are in gsmtap_util.c and >> the one to send the messages on the socket is called by l1ctl.c am I right? >> Can you help me understanding why I cannot see all the messages? >> >> thank you in advance >> Loretta > >Hi, > >I've had this happen to me when I wasn't receiving the gsmtap packets. > >Specifically, I had the gsmtap packets sent over the network (i.e., >non-localhost). There was no UDP listener on the receiving end, such >that ICMP port-unreachable replies were being sent back. It would >appear that this causes the sender's kernel to snub some of the >outgoing packets. I don't know if the same happens on localhost. > >If this is your case, you can try "iptables -I INPUT -p udp -d 4729 -j >DROP", or something like "nc -l -u 4729 > /dev/null". > >Cheers, >Alex > > From 246tnt at gmail.com Fri May 6 08:14:37 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Fri, 06 May 2011 08:14:37 +0000 Subject: R: Re: lost dump ?!?!? In-Reply-To: <13802439.1039031304669490908.JavaMail.defaultUser@defaultHost> Message-ID: <20cf302d4d18b1c26804a297143b@google.com> > I actually played a bit with the code and found out that exactly half of > the > times the write() call in the function > gsmtap_fd_cb() (gsmtap_util.c) fails because of EAGAIN or EWOULDBLOCK. That's because of what Alex said. If you do what he described, the port unreachable will not happen and all write will succeed. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri May 6 08:53:48 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 6 May 2011 10:53:48 +0200 Subject: R: Re: lost dump ?!?!? In-Reply-To: <13802439.1039031304669490908.JavaMail.defaultUser@defaultHost> References: <13802439.1039031304669490908.JavaMail.defaultUser@defaultHost> Message-ID: <20110506085348.GN29049@prithivi.gnumonks.org> Loretta, the problem is just because there is no UDP listener. Once somebody listens on UDP 127.0.0.1:4729, I think there should be no write() errors anymore. Can you please verify this? If you do have a listener on the UDP port and still get write errors, we need to fix something in 'mobile'. Otherwise, no need for that... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri May 6 09:11:10 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 6 May 2011 11:11:10 +0200 Subject: simtrace: New mailing list / progress Message-ID: <20110506091110.GO29049@prithivi.gnumonks.org> Hi all! Since Kevin and I are trying to re-vitalize the simtrace project, I have decided to create a new simtrace at lists.osmocom.org mailing list dedicated to this project. Yesterday at a meeting we have discussed * to use a digitally-controlled analog switch to select sniffing / emulation mode (i.e. to do a software-controlled 'cut' the electrical connection between the SIM card and the phone) * to add a header next to the USB socket so we can attach a battery pack for autonomous operation * to add a SPI NOR flash (for storage of data in autonomous operation) * to not care about 1.8V-only SIM cards and make it a 3.3V-only device We expect to do a bit more schematics review and component placement + routing as well as a prototype PCB in the next couple of weeks. Kevin is in charge of the hardware prototype, while I will look at the firmware side as well as provide funding for the PCB manufacturing and prototype components. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From screaming-pain at libero.it Fri May 6 11:28:41 2011 From: screaming-pain at libero.it (screaming-pain at libero.it) Date: Fri, 6 May 2011 13:28:41 +0200 (CEST) Subject: R: Re: R: Re: lost dump ?!?!? Message-ID: <33466355.1165231304681321223.JavaMail.defaultUser@defaultHost> Thanks Sylvain, Harald and Alex, > >Can you please verify this? If you do have a listener on the UDP port >and still get write errors, we need to fix something in 'mobile'. >Otherwise, no need for that... > I was using nc -u -l 4729 > /dev/null I added the -p option and tried again: as you said this solved the problem!!! Thanks again, Loretta From wolfram at the-dreams.de Fri May 6 21:57:01 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Fri, 6 May 2011 23:57:01 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent Message-ID: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> * convert *_UART_NR to enum uart_type in uart.h * make uart-functions use uart_type consistently (was uint8_t and int) * map uart_type to correct uart for mtk * (remove forgotten calypso-include for mtk while we are here) Binaries have been successfully tested with a Sciphone G2 and a Motorola C155. Signed-off-by: Wolfram Sang --- And I just wanted to get rid of some build warnings ;) src/target/firmware/board/mediatek/uart.c | 31 ++++++++++++--------------- src/target/firmware/calypso/uart.c | 26 +++++++++++----------- src/target/firmware/include/comm/sercomm.h | 4 --- src/target/firmware/include/console.h | 3 -- src/target/firmware/include/uart.h | 21 +++++++++++------- 5 files changed, 40 insertions(+), 45 deletions(-) diff --git a/src/target/firmware/board/mediatek/uart.c b/src/target/firmware/board/mediatek/uart.c index ff82245..6a87473 100644 --- a/src/target/firmware/board/mediatek/uart.c +++ b/src/target/firmware/board/mediatek/uart.c @@ -36,8 +36,6 @@ #include -#include - /* MT622x */ #if 0 #define BASE_ADDR_UART1 0x80130000 @@ -48,8 +46,7 @@ /* MT 6235 */ #define BASE_ADDR_UART1 0x81030000 -//TODO make UART2 and 3 work -#define UART_REG(n,m) (BASE_ADDR_UART1 + (m)) +#define UART_REG(n,m) (BASE_ADDR_UART1 + (!n) * 0x10000 + (m)) #define LCR7BIT 0x80 #define LCRBFBIT 0x40 @@ -112,7 +109,7 @@ enum iir_bits { /* enable or disable the divisor latch for access to DLL, DLH */ -static void uart_set_lcr7bit(int uart, int on) +static void uart_set_lcr7bit(enum uart_type uart, int on) { uint8_t reg; @@ -125,7 +122,7 @@ static void uart_set_lcr7bit(int uart, int on) } static uint8_t old_lcr; -static void uart_set_lcr_bf(int uart, int on) +static void uart_set_lcr_bf(enum uart_type uart, int on) { if (on) { old_lcr = readb(UART_REG(uart, LCR)); @@ -136,7 +133,7 @@ static void uart_set_lcr_bf(int uart, int on) } /* Enable or disable the TCR_TLR latch bit in MCR[6] */ -static void uart_set_mcr6bit(int uart, int on) +static void uart_set_mcr6bit(enum uart_type uart, int on) { uint8_t mcr; /* we assume EFR[4] is always set to 1 */ @@ -148,7 +145,7 @@ static void uart_set_mcr6bit(int uart, int on) writeb(mcr, UART_REG(uart, MCR)); } -static void uart_reg_write(int uart, enum uart_reg reg, uint8_t val) +static void uart_reg_write(enum uart_type uart, enum uart_reg reg, uint8_t val) { if (reg & LCRBFBIT) uart_set_lcr_bf(uart, 1); @@ -168,7 +165,7 @@ static void uart_reg_write(int uart, enum uart_reg reg, uint8_t val) } /* read from a UART register, applying any required latch bits */ -static uint8_t uart_reg_read(int uart, enum uart_reg reg) +static uint8_t uart_reg_read(enum uart_type uart, enum uart_reg reg) { uint8_t ret; @@ -271,7 +268,7 @@ static void uart_irq_handler_sercomm(__unused int irqnr) } } -void uart_init(uint8_t uart, __unused uint8_t interrupts) +void uart_init(enum uart_type uart, __unused uint8_t interrupts) { /* no interrupts, only polling so far */ @@ -302,7 +299,7 @@ void uart_init(uint8_t uart, __unused uint8_t interrupts) uart_set_lcr7bit(uart, 0); } -void uart_poll(uint8_t uart) { +void uart_poll(enum uart_type uart) { if(uart == CONS_UART_NR) { uart_irq_handler_cons(0); } else { @@ -310,7 +307,7 @@ void uart_poll(uint8_t uart) { } } -void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on) +void uart_irq_enable(enum uart_type uart, enum uart_irq irq, int on) { uint8_t ier = uart_reg_read(uart, IER); uint8_t mask = 0; @@ -333,7 +330,7 @@ void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on) } -void uart_putchar_wait(uint8_t uart, int c) +void uart_putchar_wait(enum uart_type uart, int c) { /* wait while TX FIFO indicates full */ while (~readb(UART_REG(uart, LSR)) & 0x20) { } @@ -342,7 +339,7 @@ void uart_putchar_wait(uint8_t uart, int c) writeb(c, UART_REG(uart, RBR)); } -int uart_putchar_nb(uint8_t uart, int c) +int uart_putchar_nb(enum uart_type uart, int c) { /* if TX FIFO indicates full, abort */ if (~readb(UART_REG(uart, LSR)) & 0x20) @@ -352,7 +349,7 @@ int uart_putchar_nb(uint8_t uart, int c) return 1; } -int uart_getchar_nb(uint8_t uart, uint8_t *ch) +int uart_getchar_nb(enum uart_type uart, uint8_t *ch) { uint8_t lsr; @@ -379,7 +376,7 @@ int uart_getchar_nb(uint8_t uart, uint8_t *ch) return 1; } -int uart_tx_busy(uint8_t uart) +int uart_tx_busy(enum uart_type uart) { /* Check THRE bit (LSR[5]) to see if FIFO is full */ if (~readb(UART_REG(uart, LSR)) & 0x20) @@ -409,7 +406,7 @@ static const uint16_t divider[] = { [UART_921600] = 7, /* would need UART_REG(HIGHSPEED) = 1 */ }; -int uart_baudrate(uint8_t uart, enum uart_baudrate bdrt) +int uart_baudrate(enum uart_type uart, enum uart_baudrate bdrt) { uint16_t div; diff --git a/src/target/firmware/calypso/uart.c b/src/target/firmware/calypso/uart.c index d3ede4d..0355ee2 100644 --- a/src/target/firmware/calypso/uart.c +++ b/src/target/firmware/calypso/uart.c @@ -112,7 +112,7 @@ enum iir_bits { #define UART_REG_UIR 0xffff6000 /* enable or disable the divisor latch for access to DLL, DLH */ -static void uart_set_lcr7bit(int uart, int on) +static void uart_set_lcr7bit(enum uart_type uart, int on) { uint8_t reg; @@ -125,7 +125,7 @@ static void uart_set_lcr7bit(int uart, int on) } static uint8_t old_lcr; -static void uart_set_lcr_bf(int uart, int on) +static void uart_set_lcr_bf(enum uart_type uart, int on) { if (on) { old_lcr = readb(UART_REG(uart, LCR)); @@ -136,7 +136,7 @@ static void uart_set_lcr_bf(int uart, int on) } /* Enable or disable the TCR_TLR latch bit in MCR[6] */ -static void uart_set_mcr6bit(int uart, int on) +static void uart_set_mcr6bit(enum uart_type uart, int on) { uint8_t mcr; /* we assume EFR[4] is always set to 1 */ @@ -148,7 +148,7 @@ static void uart_set_mcr6bit(int uart, int on) writeb(mcr, UART_REG(uart, MCR)); } -static void uart_reg_write(int uart, enum uart_reg reg, uint8_t val) +static void uart_reg_write(enum uart_type uart, enum uart_reg reg, uint8_t val) { if (reg & LCRBFBIT) uart_set_lcr_bf(uart, 1); @@ -168,7 +168,7 @@ static void uart_reg_write(int uart, enum uart_reg reg, uint8_t val) } /* read from a UART register, applying any required latch bits */ -static uint8_t uart_reg_read(int uart, enum uart_reg reg) +static uint8_t uart_reg_read(enum uart_type uart, enum uart_reg reg) { uint8_t ret; @@ -276,7 +276,7 @@ static const uint8_t uart2irq[] = { [1] = IRQ_UART_MODEM, }; -void uart_init(uint8_t uart, uint8_t interrupts) +void uart_init(enum uart_type uart, uint8_t interrupts) { uint8_t irq = uart2irq[uart]; @@ -330,7 +330,7 @@ void uart_init(uint8_t uart, uint8_t interrupts) uart_set_lcr7bit(uart, 0); } -void uart_poll(uint8_t uart) { +void uart_poll(enum uart_type uart) { if(uart == CONS_UART_NR) { uart_irq_handler_cons(0); } else { @@ -338,7 +338,7 @@ void uart_poll(uint8_t uart) { } } -void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on) +void uart_irq_enable(enum uart_type uart, enum uart_irq irq, int on) { uint8_t ier = uart_reg_read(uart, IER); uint8_t mask = 0; @@ -361,7 +361,7 @@ void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on) } -void uart_putchar_wait(uint8_t uart, int c) +void uart_putchar_wait(enum uart_type uart, int c) { /* wait while TX FIFO indicates full */ while (readb(UART_REG(uart, SSR)) & 0x01) { } @@ -370,7 +370,7 @@ void uart_putchar_wait(uint8_t uart, int c) writeb(c, UART_REG(uart, THR)); } -int uart_putchar_nb(uint8_t uart, int c) +int uart_putchar_nb(enum uart_type uart, int c) { /* if TX FIFO indicates full, abort */ if (readb(UART_REG(uart, SSR)) & 0x01) @@ -380,7 +380,7 @@ int uart_putchar_nb(uint8_t uart, int c) return 1; } -int uart_getchar_nb(uint8_t uart, uint8_t *ch) +int uart_getchar_nb(enum uart_type uart, uint8_t *ch) { uint8_t lsr; @@ -407,7 +407,7 @@ int uart_getchar_nb(uint8_t uart, uint8_t *ch) return 1; } -int uart_tx_busy(uint8_t uart) +int uart_tx_busy(enum uart_type uart) { if (readb(UART_REG(uart, SSR)) & 0x01) return 1; @@ -423,7 +423,7 @@ static const uint16_t divider[] = { [UART_921600] = 1, /* 812,500! (-3% would be 893,952) */ }; -int uart_baudrate(uint8_t uart, enum uart_baudrate bdrt) +int uart_baudrate(enum uart_type uart, enum uart_baudrate bdrt) { uint16_t div; diff --git a/src/target/firmware/include/comm/sercomm.h b/src/target/firmware/include/comm/sercomm.h index 54256b5..4c23b31 100644 --- a/src/target/firmware/include/comm/sercomm.h +++ b/src/target/firmware/include/comm/sercomm.h @@ -1,12 +1,8 @@ #ifndef _SERCOMM_H #define _SERCOMM_H -/* SERCOMM layer on UART1 (modem UART) */ - #include -#define SERCOMM_UART_NR 1 - #define HDLC_FLAG 0x7E #define HDLC_ESCAPE 0x7D diff --git a/src/target/firmware/include/console.h b/src/target/firmware/include/console.h index 7146e99..b5a83f5 100644 --- a/src/target/firmware/include/console.h +++ b/src/target/firmware/include/console.h @@ -11,9 +11,6 @@ int cons_putchar(char c); int cons_rb_flush(void); void cons_init(void); -/* We want the console on UART 0 (IRDA UART) */ -#define CONS_UART_NR 0 - /* Size of the static ring-buffer that we keep for console print messages */ #define CONS_RB_SIZE 4096 diff --git a/src/target/firmware/include/uart.h b/src/target/firmware/include/uart.h index 81d7a15..eedb006 100644 --- a/src/target/firmware/include/uart.h +++ b/src/target/firmware/include/uart.h @@ -3,6 +3,11 @@ #include +enum uart_type { + CONS_UART_NR, + SERCOMM_UART_NR, +}; + enum uart_baudrate { UART_38400, UART_57600, @@ -13,20 +18,20 @@ enum uart_baudrate { UART_921600, }; -void uart_init(uint8_t uart, uint8_t interrupts); -void uart_putchar_wait(uint8_t uart, int c); -int uart_putchar_nb(uint8_t uart, int c); -int uart_getchar_nb(uint8_t uart, uint8_t *ch); -int uart_tx_busy(uint8_t uart); -int uart_baudrate(uint8_t uart, enum uart_baudrate bdrt); +void uart_init(enum uart_type uart, uint8_t interrupts); +void uart_putchar_wait(enum uart_type uart, int c); +int uart_putchar_nb(enum uart_type uart, int c); +int uart_getchar_nb(enum uart_type uart, uint8_t *ch); +int uart_tx_busy(enum uart_type uart); +int uart_baudrate(enum uart_type uart, enum uart_baudrate bdrt); enum uart_irq { UART_IRQ_TX_EMPTY, UART_IRQ_RX_CHAR, }; -void uart_irq_enable(uint8_t uart, enum uart_irq irq, int on); +void uart_irq_enable(enum uart_type uart, enum uart_irq irq, int on); -void uart_poll(uint8_t uart); +void uart_poll(enum uart_type uart); #endif /* _UART_H */ -- 1.7.2.5 From 246tnt at gmail.com Sat May 7 05:21:05 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 7 May 2011 07:21:05 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> References: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> Message-ID: Hi, > * convert *_UART_NR to enum uart_type in uart.h > * make uart-functions use uart_type consistently > (was uint8_t and int) > * map uart_type to correct uart for mtk > * (remove forgotten calypso-include for mtk while we are here) > > Binaries have been successfully tested with a Sciphone G2 and a Motorola C155. > > Signed-off-by: Wolfram Sang > --- This looks very weird to me ... The uart paraemeter is not a 'type', it's the index of the UART. And we use define so we can easily change if we use UART0 or UART1 for the console / sercomm. With your modification you have to change the order of the enum if you want to swap them ? (like it's required on the freerunner) There is someclean up to be made, but IMHO that's not it at all. Cheers, Sylvain From wolfram at the-dreams.de Sat May 7 07:15:55 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sat, 07 May 2011 09:15:55 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: References: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> Message-ID: <4DC4F1AB.4090803@the-dreams.de> On 07/05/11 07:21, Sylvain Munaut wrote: > Hi, > >> * convert *_UART_NR to enum uart_type in uart.h >> * make uart-functions use uart_type consistently >> (was uint8_t and int) >> * map uart_type to correct uart for mtk >> * (remove forgotten calypso-include for mtk while we are here) >> >> Binaries have been successfully tested with a Sciphone G2 and a Motorola C155. >> >> Signed-off-by: Wolfram Sang >> --- > > > This looks very weird to me ... Sorry, then my descriptive text was not good enough :( > The uart paraemeter is not a 'type', it's the index of the UART. And > we use define so we can easily change if we use UART0 or UART1 for the > console / sercomm. That was what I intentionally wanted to change, because it caused problems for MTK. > With your modification you have to change the order of the enum if you > want to swap them ? (like it's required on the freerunner) The enums should never be changed; that is the meaning of it all. The idea is to have consistent ids for the type of uart across the whole tree and have it mapped to the correct uart only in the platform specific uart.c just before accessing the registers. So, this is some kind of virtual UART_NR which gets mapped to the internal uart very late. Probaby they should be renamed to simply CONS_UART (instead of CONS_UART_NR) then. MTK also needs them to be swapped. This is why I can't first compile 'firmware' and then 'mtk-firmware', because lib/console.c won't get recompiled and will still use the non-swapped *_UART_NR. And IMO it should not be recompiled, thus the added layer of abstraction. The freerunner should have the same problem, but I can't find the code which swaps the uarts? > There is someclean up to be made, but IMHO that's not it at all. Yup, found some local uart-variables. Do you mean that? Thanks, Wolfram From 246tnt at gmail.com Sat May 7 08:04:25 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 7 May 2011 10:04:25 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: <4DC4F1AB.4090803@the-dreams.de> References: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> <4DC4F1AB.4090803@the-dreams.de> Message-ID: > The enums should never be changed; that is the meaning of it all. The idea > is to have consistent ids for the type of uart across the whole tree and > have it mapped to the correct uart only in the platform specific uart.c But it is not "platform" specific, it is _board_ specific. So the same driver uart.c must deal with several mapping. IMHO drivers should get as parameter the index of the device you want to address and not some global id and map it internally to the driver. What if I want for debug to output something on UART3 or something, adding something like uart_putc(3, 'b') is much easier than having to go add a new value for the enum and its mapping ... If something doesn't get recompiled when a header change or something, you must fix the build system. The current system of trying to build for all platforms at once is unsustainable IMHO and we should just have something like make TARGET=compal_e88 make TARGET=sciphone_g2 or something and if the TARGET is != from the last built target, just assume everything is dirty. Cheers, Sylvain From wolfram at the-dreams.de Sat May 7 09:04:39 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sat, 07 May 2011 11:04:39 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: References: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> <4DC4F1AB.4090803@the-dreams.de> Message-ID: <4DC50B27.9090000@the-dreams.de> On 07/05/11 10:04, Sylvain Munaut wrote: >> The enums should never be changed; that is the meaning of it all. The idea >> is to have consistent ids for the type of uart across the whole tree and >> have it mapped to the correct uart only in the platform specific uart.c > > But it is not "platform" specific, it is _board_ specific. So the same > driver uart.c must deal with several mapping. Yes, I know. Ultimately, there should be something like "#include " which will pull in the correct settings per board. But that seemed overkill to me for now (seeing that there might be a move to an RTOS anyway). I thought board differences can be easier handled on a per-platform basis until then. > IMHO drivers should get as parameter the index of the device you want > to address and not some global id and map it internally to the driver. > > What if I want for debug to output something on UART3 or something, > adding something like uart_putc(3, 'b') is much easier than having to > go add a new value for the enum and its mapping ... That is easier, but not portable. What if some other board doesn't have a UART3? Adding MY_DEBUG_UART does not really hurt IMHO and other boards will notice that there is something to take care of. > If something doesn't get recompiled when a header change or something, > you must fix the build system. This is true, of course... > The current system of trying to build for all platforms at once is > unsustainable IMHO and we should just have something like > make TARGET=compal_e88 make TARGET=sciphone_g2 or something and if ... right, too ... > the TARGET is != from the last built target, just assume everything is > dirty. ... though in my book, lib/console.c should not recompile if the underlying platform changes (arch is something different, of course ;)). If lib/* depends on the platform (like with UART numbering), to me this sounds like something to be fixed. I don't feel strong about this patch, though. If it is not good enough, we can just skip it. I start to wonder if it makes sense to do such kind of work before the RTOS comes along? Regards, Wolfram From 246tnt at gmail.com Sat May 7 09:37:11 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Sat, 07 May 2011 09:37:11 +0000 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: <4DC50B27.9090000@the-dreams.de> Message-ID: <001636416869cbcf9604a2ac597e@google.com> > ... though in my book, lib/console.c should not recompile if the > underlying platform changes (arch is something different, of course ;)). > If lib/* depends on the platform (like with UART numbering), to me this > sounds like something to be fixed. IMHO board startup functions shoudl have a call like console_init( XXX ) with XXX being the uart index to start the console on. > I don't feel strong about this patch, though. If it is not good enough, > we can just skip it. Yes sorry but I really don't like the drivers being put in charge of a mapping. > I start to wonder if it makes sense to do such kind of work before the > RTOS comes along? Indeed, good question ... Cheers, Sylvain Munaut -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfram at the-dreams.de Mon May 9 16:56:27 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 09 May 2011 18:56:27 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: <001636416869cbcf9604a2ac597e@google.com> References: <001636416869cbcf9604a2ac597e@google.com> Message-ID: <4DC81CBB.6050902@the-dreams.de> > > I start to wonder if it makes sense to do such kind of work before > the RTOS comes along? > > Indeed, good question ... Having thought about this issue every now and then, I currently feel more tempted to port the g2-loader to NuttX, just to have it tried and see how that ends up. Working on the current bare metal-infrastructure for multi-platform feels like a dead end somehow. Wolfram PS: I'll be in Berlin for LinuxTag from Wed to Sat. So, if somebody is interested to meet somewhen/somewhere and chat about RTOS/infrastructure (or just chat ;)), I am all for it! From laforge at gnumonks.org Sat May 7 10:10:00 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 7 May 2011 12:10:00 +0200 Subject: build system / building for all targets In-Reply-To: References: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> <4DC4F1AB.4090803@the-dreams.de> Message-ID: <20110507101000.GK8647@prithivi.gnumonks.org> On Sat, May 07, 2011 at 10:04:25AM +0200, Sylvain Munaut wrote: > The current system of trying to build for all platforms at once is > unsustainable IMHO and we should just have something like > make TARGET=compal_e88 make TARGET=sciphone_g2 or something and if > the TARGET is != from the last built target, just assume everything is > dirty. I intentionally did it the way it currently is: to ensure we don't have bit-rot of non-building code in the tree. So whatever we do in the future, especially with the small code size we deal, I would like to keep it the way that by default we build every image for every target. We can have a TARGET=xxx as an option. This way the user can select to deviate from the default, i.e. an optimization. I understand your concern is not about build time but about the fact that different boards might #define things differently. This indeed needs to be fixed, and I think we should then probably put our .o files out of the source tree, and dynamically create a build-compal_e88 directory which contains all the compiler output for that target. If anyone wants to work on something like this, I would be happy to merge the patches. But from my point of view the default make file target should then still build all the .c files for all the targets. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat May 7 10:13:50 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 7 May 2011 12:13:50 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: <4DC4F1AB.4090803@the-dreams.de> References: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> <4DC4F1AB.4090803@the-dreams.de> Message-ID: <20110507101350.GL8647@prithivi.gnumonks.org> Regarding the UART numbers. My view on this is: 1) I agree with Sylvain that the driver should simply take a uart-number as input, and what that number maps to should be SoC-specific. 2) We should either a) have a #define for every board (not SoC), which is something like #define CONS_UART_NR 0" and which is then used in the actual callers of the uart driver, or b) have a global board-configuration structure which gets filled in by the board_init() code, which then contains a boardcf->cons_uart_nr member whihc can be used by the callers of the uart driver. '2a' requires that we modify our build system to make per-board compiles. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jakob at weite-welt.com Wed May 18 05:11:40 2011 From: jakob at weite-welt.com (Leif Jakob) Date: Wed, 18 May 2011 07:11:40 +0200 Subject: [PATCH] uart: make *_UART_NR platform independent In-Reply-To: <20110507101350.GL8647@prithivi.gnumonks.org> References: <1304719021-23901-1-git-send-email-wolfram@the-dreams.de> <4DC4F1AB.4090803@the-dreams.de> <20110507101350.GL8647@prithivi.gnumonks.org> Message-ID: <20110518051139.GA26189@aegir.asgard.sol> On Sat, May 07, 2011 at 12:13:50PM +0200 Harald Welte wrote: > Date: Sat, May 07, 2011 at 12:13:50PM +0200 > From: Harald Welte > To: > Subject: [PATCH] uart: make *_UART_NR platform independent Hi, > b) have a global board-configuration structure which gets filled in by the > board_init() code, which then contains a boardcf->cons_uart_nr > member whihc can be used by the callers of the uart driver. attached is my local patch I tried to get merged some time ago that implements the board structure. It needs no active initialization and has default values (see patch). Cheers Leif -------------- next part -------------- A non-text attachment was scrubbed... Name: sercon.patch Type: text/x-diff Size: 4777 bytes Desc: not available URL: From wbg_1000 at yahoo.com Sat May 7 07:25:33 2011 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Sat, 7 May 2011 00:25:33 -0700 (PDT) Subject: Fw: Re: mobile - making a call Message-ID: <236835.52177.qm@web112115.mail.gq1.yahoo.com> So any ideea where to look for the answer to the UPDATE_BINARY message? Can I have a buffer overflow on UART RX? Is the buffer size selectable somewhere? --- On Wed, 5/4/11, eisencah eisenach wrote: From: eisencah eisenach Subject: Re: mobile - making a call To: baseband-devel at lists.osmocom.org Date: Wednesday, May 4, 2011, 4:58 PM Done some more digging in the logs and it seems the sim state machine has locked earlier (when attaching to the network)? while waiting for some response on UPDATE BINARY. Does this sounds familiar to anyone? :) GOOD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:151 sending result to callback function (type=0) [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) BAD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated --- On Wed, 5/4/11, Harald Welte wrote: From: Harald Welte Subject: Re: mobile - making a call To: "eisencah eisenach" Date: Wednesday, May 4, 2011, 11:59 AM On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote: > So is as if the message for the sim job doesn't get pulled from the > queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears.? Must say > the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz > celeron with ubuntu 6.10) , and It gets slowed down when running the > hole thing. Can that be the cause?? Mihai. The L1CTL protocol goes through a unix domain socket, and you can trace it in either osmocon or in the mobile program itself.? It should be relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile, or if it is lost, where it is lost. -- - Harald Welte ? ? ? ? ???http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat May 7 08:07:15 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 7 May 2011 10:07:15 +0200 Subject: Fw: Re: mobile - making a call In-Reply-To: <236835.52177.qm@web112115.mail.gq1.yahoo.com> References: <236835.52177.qm@web112115.mail.gq1.yahoo.com> Message-ID: > So any ideea where to look for the answer to the UPDATE_BINARY message? No not really ... But there is a good reason the SIM driver is not in master ... it sucks at several level, including blocking behavior in interrupt context IIRC, so it's totally plausible your machine speed triggers some weird things. My advice would be to: - Cleanup the SIM driver - Bypass it in the code and try to access a real PCSC device locally rather than the built in SIM reader. Both are non-trivial of course. Cheers, Sylvain From osmocom at ngolde.de Mon May 9 10:12:49 2011 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 9 May 2011 12:12:49 +0200 Subject: Fw: Re: mobile - making a call In-Reply-To: References: <236835.52177.qm@web112115.mail.gq1.yahoo.com> Message-ID: <20110509101248.GA23463@segfault.binarybase.org> Hi, * Sylvain Munaut <246tnt at gmail.com> [2011-05-09 11:30]: > > So any ideea where to look for the answer to the UPDATE_BINARY message? > > No not really ... > > But there is a good reason the SIM driver is not in master ... it > sucks at several level, including blocking behavior in interrupt > context IIRC, so it's totally plausible your machine speed triggers > some weird things. > > My advice would be to: > - Cleanup the SIM driver > - Bypass it in the code and try to access a real PCSC device locally > rather than the built in SIM reader. > > Both are non-trivial of course. If you wait a bit you will get code for the second suggestion. We currently have a working version that forwards the apdu to a local client transforming this into SAP and speaking with a SAP server that uses pcsc to talk to a SIM card in an external SIM reader. My goal though is to transform this into a complete SAP client in sap_interface.c, I will work on that now... Cheers Nico From wbg_1000 at yahoo.com Sun May 15 14:52:44 2011 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Sun, 15 May 2011 07:52:44 -0700 (PDT) Subject: Fw: Re: mobile - making a call In-Reply-To: Message-ID: <915898.60768.qm@web112105.mail.gq1.yahoo.com> Hi again. So after some digging I'm quite sure the ADPU response doesn't make it back into the upper layers. My question is , case the osmocon output contains some weird characters (see bellow), I should assume that at that point something went wrong with the serial link? Also is there some flag to compile the firmware such that the prints have no effect, as to offload the serial link? Thanks, Mihai. L1CTL_DATA_REQ (link_id=0x00) ul=00811fe0, ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4 SIM Request (7): a0 a4 00 00 02 6f 20 Status 2: 9F 0F SIM Request (5): a0 c0 00 00 0f Status 1: 90 00 SIM Request (14): a0 d6 00 00 09 ff 49 fd 1a 49 8f 70 00 01 Status 2: 90??????Q??????L1CTL_PARAM_REQ (ta=1, tx_power=6) L1CTL_DATA_REQ (link_id=0x00) ul=00811fe0, ul->payload=00811fe4, data_ind=00811fe4, data_ind->data=00811fe4 l3h=00811fe4 L1CTL_DATA_REQ (link_id=0x00) ul=008123c4, ul->payload=008123c8, data_ind=008123c8, data_ind->data=008123c8 l3h=008123c8 --- On Sat, 5/7/11, Sylvain Munaut <246tnt at gmail.com> wrote: From: Sylvain Munaut <246tnt at gmail.com> Subject: Re: Fw: Re: mobile - making a call To: "eisencah eisenach" Cc: baseband-devel at lists.osmocom.org Date: Saturday, May 7, 2011, 11:07 AM > So any ideea where to look for the answer to the UPDATE_BINARY message? No not really ... But there is a good reason the SIM driver is not in master ... it sucks at several level, including blocking behavior in interrupt context IIRC, so it's totally plausible your machine speed triggers some weird things. My advice would be to: - Cleanup the SIM driver - Bypass it in the code and try to access a real PCSC device locally rather than the built in SIM reader. Both are non-trivial of course. Cheers, ? ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm.engineer84 at gmail.com Sat May 7 17:00:52 2011 From: rm.engineer84 at gmail.com (R M) Date: Sat, 7 May 2011 22:30:52 +0530 Subject: T191 unlock cable Message-ID: Hi This is my first mail to this list. I have downloaded the code and compiled it. My development environment is Eclipse using cygwin as I am a Windows user. I have succeeded in procuring Motorola C115 phone and also T191 unlock cable but the cable has a serial port on one end and 2.5 mm audio jack at the other. My laptop doesn't have a serial port. It only has USB ports. What sort of USB to serial converter should I use? I have not enquired the cost of FDTI cables in India. But they seem to cost a fortune online. Please do suggest one that is cheap say within 200 rupees. I am also having difficulty downloading Iota and Rita data sheets as the links provided in the wiki lead to chinese sites and I don't understand chinese. Can some one who has already downloaded them please tell me the process like which buttons I need to click etc. Regards, RM -------------- next part -------------- An HTML attachment was scrubbed... URL: From wpatan at gmail.com Mon May 9 01:42:51 2011 From: wpatan at gmail.com (wpatan) Date: Sun, 8 May 2011 18:42:51 -0700 (PDT) Subject: T191 unlock cable In-Reply-To: References: Message-ID: <1304905371686-2917191.post@n3.nabble.com> Hello, I suggest you purchase those Prolific based cables. It's much cheaper compared to FTDI cables. You wont be needing FTDI unless you plan to test the "burst" branch. Cheers! Wpatan -- View this message in context: http://baseband-devel.722152.n3.nabble.com/T191-unlock-cable-tp2912575p2917191.html Sent from the baseband-devel mailing list archive at Nabble.com. From rm.engineer84 at gmail.com Mon May 23 16:34:05 2011 From: rm.engineer84 at gmail.com (R M) Date: Mon, 23 May 2011 22:04:05 +0530 Subject: T191 unlock cable In-Reply-To: <1304905371686-2917191.post@n3.nabble.com> References: <1304905371686-2917191.post@n3.nabble.com> Message-ID: Hi, Thanks wpatan. I am planning to buy this cable http://www.tronisoft.com/prod.php?id=2441. Is it OK for using it with T191 unlock cable. Regards, RM On Mon, May 9, 2011 at 7:12 AM, wpatan wrote: > Hello, > > I suggest you purchase those Prolific based cables. It's much cheaper > compared to FTDI cables. > You wont be needing FTDI unless you plan to test the "burst" branch. > > Cheers! > Wpatan > > -- > View this message in context: > http://baseband-devel.722152.n3.nabble.com/T191-unlock-cable-tp2912575p2917191.html > Sent from the baseband-devel mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wpatan at gmail.com Tue May 24 01:11:00 2011 From: wpatan at gmail.com (wpatan) Date: Mon, 23 May 2011 18:11:00 -0700 (PDT) Subject: T191 unlock cable In-Reply-To: References: <1304905371686-2917191.post@n3.nabble.com> Message-ID: <1306199460492-2977859.post@n3.nabble.com> Yep. This is a standard USB to Serial adapter.. it's based on a Prolific chipset. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/T191-unlock-cable-tp2912575p2977859.html Sent from the baseband-devel mailing list archive at Nabble.com. From ichgeh at l--putt.de Sat May 7 20:34:12 2011 From: ichgeh at l--putt.de (l--putt) Date: Sat, 07 May 2011 22:34:12 +0200 Subject: SPMA100B ringtone chip Message-ID: <4DC5ACC4.70307@l--putt.de> Hi list! To get closer to a useful phone, I started a project to create a driver for the SPMA100B ringtone chip of the C155. I can replay the commands to play the startup and shutdown sounds and have some idea about the registers. A problem is the MIDI(?) data send to the chip: It's possible to extract the MIDI files from a flash image but the tracks are interleaved by the firmware. Some random single track files don't work either. Anybody an idea? I've found other datasheets (in particular for the W56964 of the DPL10) and they helped a lot in understanding the SPMA100B due to the similarities. Hence, I suggest a common framework for all those chips. However, even salsa (embedded version of ALSA) seems excessive since we have just a single device. I considered a really simple design with just single write-call that blocks until played. Some ioctl solve volume etc. But this doesn't communicate the state (playing, fifo empty, finished, error) well. Any ideas? Does anybody know cc-licensed MIDI ringtones? http://www.ringtonepirates.de/ seems to have only MP3 sounds. Given its name, you also need balls to download there (at least in Germany: "offensichtlich illegale Quelle" :-P ) Regards, Stefan A hack of hello_world example to play ringtones on SPMA100B chip --- src/target/firmware/apps/hello_world/main.c | 330 ++++++++++++++++++++++++++- 1 files changed, 328 insertions(+), 2 deletions(-) diff --git a/src/target/firmware/apps/hello_world/main.c b/src/target/firmware/apps/hello_world/main.c index 5e3ed85..f247795 100644 --- a/src/target/firmware/apps/hello_world/main.c +++ b/src/target/firmware/apps/hello_world/main.c @@ -68,6 +68,310 @@ static void l1a_l23_rx_cb(uint8_t dlci, struct msgb *msg) puts("\n"); } +/* Define GPIO interface */ +#define ARMIO_LATCH_OUT 0xfffe4802 +#define IO_CNTL_REG 0xfffe4804 +#define ASIC_CONF_REG 0xfffef008 + +#define IO_CONF_REG 0xfffef00a +#define CALYPSO_CONF_OFF 4 + +#define CALYPSO_IO4 (1 << 4) +#define CALYPSO_IO7 (1 << 7) +#define CALYPSO_IO8 (1 << 8) +#define CALYPSO_IO12 (1 << 12) + +#define GPIO_ENABLE(pins) { \ + uint16_t reg = readw(IO_CONF_REG); \ + reg |= (pins) >> CALYPSO_CONF_OFF; \ + writew(reg, IO_CONF_REG); } + +#define GPIO_OUTPUT(pins) { \ + uint16_t reg = readw(IO_CNTL_REG); \ + reg &= ~(pins); \ + writew(reg, IO_CNTL_REG); } + +#define GPIO_SET(pins) { \ + uint16_t reg = readw(ARMIO_LATCH_OUT); \ + reg |= (pins); \ + writew(reg, ARMIO_LATCH_OUT); } + +#define GPIO_UNSET(pins) { \ + uint16_t reg = readw(ARMIO_LATCH_OUT); \ + reg &= ~(pins); \ + writew(reg, ARMIO_LATCH_OUT); } + +/* Define W569x constants */ +#define MUSIC_REG 0x01800000 + +#define MUSIC_IRQ CALYPSO_IO4 +#define MUSIC_A0 CALYPSO_IO8 +#define MUSIC_ON CALYPSO_IO12 + +static uint8_t spma100_regread(uint8_t bank) +{ + GPIO_UNSET(MUSIC_A0); + delay_ms(1); + writeb(bank, MUSIC_REG); + GPIO_SET(MUSIC_A0); + + delay_ms(1); + + return readb(MUSIC_REG); +} + +static void spma100_dumpregs(void) +{ + int i; + for(i=0; i<256; i++) { + printf("%02x,", spma100_regread(i)); + } + printf("\n\n"); +} + +static void spma100_deltaregs(void) +{ + int i; + static uint8_t state[256]; + for(i=0; i<256; i++) { + char tmp = spma100_regread(i); + if(tmp ^ state[i]) + printf("%02x: %02x, changed by %02x\n", i, tmp, tmp ^ state[i]); + state[i] = tmp; + } + printf("\n\n"); +} + +static void spma100_regwrite(uint8_t bank, uint8_t data) +{ + GPIO_UNSET(MUSIC_A0); + delay_ms(1); + writeb(bank, MUSIC_REG); + GPIO_SET(MUSIC_A0); + + delay_ms(1); + + writeb(data, MUSIC_REG); + + delay_ms(1); + + //spma100_dumpregs(); + //spma100_deltaregs(); +} + +void music_onoff(int on) +{ + uint16_t reg = readw(0xfffe4802); + + if(on) { + reg |= 0x1000; + } else { + reg &= 0xefff; + } + + writew(reg, 0xfffe4802); +} + +/* HW init */ +void music_init(void) +{ + GPIO_ENABLE(MUSIC_ON); + GPIO_OUTPUT(MUSIC_ON); + + GPIO_ENABLE(MUSIC_IRQ); + + GPIO_ENABLE(MUSIC_A0); + GPIO_OUTPUT(MUSIC_A0); + + writeb(2, 0xfffe4818); + printf("GPIO event mode %x\n", readw(0xfffe4814)); + + music_onoff(1); +} + +int play_midi = -1; +static char midi1[] = {0x72, 0xab, 0x62, 0x00, 0xb0, 0xb3, 0x7f, 0xc0, 0xd2, 0x0b, 0xa7, 0x07, 0xef, 0x3c, 0xce, 0x2f, 0x5e, 0x40, 0x25, 0x3c, 0xb1, 0x07, 0x18, 0x60, 0x30, 0x7b, 0x57, 0x00, 0x91, 0x7f, 0x3f, 0x92, 0x63, 0xf3, 0x0b, 0x18, 0x47, 0xf3, 0xc1, 0x10, 0x54, 0x00, 0xb1, 0x4b, 0x7c, 0x81, 0xe1, 0x00, 0x60, 0x13, 0x50, 0xd6, 0x8a, 0x68, 0x43, 0x90, 0x43, 0x26, 0x74, 0x81, 0xc1, 0x4c, 0x18, 0x00, 0xd9, 0x2a, 0xe0, 0x63, 0x5b, 0xb0, 0x0b, 0x5b, 0x6a, 0x11, 0x37, 0x20, 0x13, 0x00, 0xf6, 0x60, 0x99, 0x70, 0xd6, 0x47, 0x63, 0x5b, 0x7e, 0x31, 0x7b, 0x51, 0x00, 0x90, 0x0c, 0x0a, 0x92, 0x70, 0xfd, 0x0b, 0x19, 0x47, 0xe1, 0xc1, 0x14, 0x54, 0x13, 0xb0, 0x43, 0x68, 0x81, 0xe0, 0x0b, 0x66, 0x13, 0x4c, 0xc2, 0x8a, 0x69, 0x4c, 0x91, 0x43, 0x29, 0x67, 0x92, 0xc0, 0x44, 0x19, 0x00, 0xd8, 0x32, 0xe6, 0x63, 0x48, 0xb1, 0x0b, 0x55, 0x77, 0x10, 0x37, 0x2b, 0x13, 0x13, 0xff, 0x73, 0x9b, 0x70, 0xdf, 0x48, 0x69, 0x40, 0x7a, 0x30, 0x7b, 0x49, 0x00, 0x91, 0x04, 0x12, 0x92, 0x63, 0xfc, 0x0b, 0x1a, 0x4f, 0xed, 0xc2, 0x1a, 0x5c, 0x00, 0xb1, 0x58, 0x64, 0x81, 0xe1, 0x10, 0x6a, 0x13, 0x47, 0xcf, 0x8e, 0x4a, 0x54, 0x90, 0x47, 0x94, 0x3c, 0x00, 0xfc, 0x5f, 0x68, 0x6b, 0x91, 0x47, 0x6b, 0xa7, 0x13, 0x71, 0x5e, 0x1b, 0xb1, 0x97, 0x10, 0x6d, 0x82, 0x3c, 0xef, 0x8a, 0x6b, 0x3c, 0x91, 0x48, 0x2d, 0x73, 0x92, 0xc0, 0x4b, 0x1b, 0x00, 0xd3, 0x2d, 0xef, 0x63, 0x43, 0xb1, 0x0b, 0x5c, 0x63, 0x10, 0x3c, 0x29, 0x13, 0x13, 0xf0, 0x6f, 0x9d, 0x70, 0xd0, 0x47, 0x70, 0x50, 0x66, 0x30, 0x7b, 0x5f, 0x00, 0x91, 0x00, 0x17, 0x92, 0x63, 0xf7, 0x0b, 0x1c, 0x48, 0xf9, 0xc9, 0x01, 0x5b, 0x00, 0xb1, 0x48, 0x76, 0x81, 0xe1, 0x0b, 0x71, 0x13, 0x54, 0xdb, 0x8a, 0x6c, 0x47, 0x90, 0x4c, 0x3b, 0x7e, 0x81, 0xc1, 0x43, 0x1c, 0x00, 0xdd, 0x22, 0xf2, 0x63, 0x5f, 0xb0, 0x0b, 0x5a, 0x70, 0x11, 0x3f, 0x33, 0x13, 0x00, 0xf9, 0x7a, 0x9c, 0x70, 0xd9, 0x4f, 0x74, 0x5f, 0x60, 0x31, 0x7b, 0x51, 0x00, 0x90, 0x07, 0x01, 0x92, 0x70, 0xfe, 0x0b, 0x1d, 0x48, 0xe4, 0xc9, 0x05, 0x5b, 0x13, 0xb0, 0x47, 0x6a, 0x81, 0xe0, 0x00, 0x77, 0x13, 0x4f, 0xc9, 0x8a, 0x6d, 0x4f, 0x91, 0x4c, 0x24, 0x69, 0x92, 0xc0, 0x58, 0x1e, 0x00, 0xdc, 0x34, 0xf9, 0x63, 0x4c, 0xb1, 0x0b, 0x51, 0x7d, 0x10, 0x3f, 0x37, 0x13, 0x13, 0xe3, 0x75, 0x9f, 0x70, 0xc3, 0x53, 0x7a, 0x47, 0x7f, 0x34, 0x5b, 0x4a, 0x00, 0x91, 0xac, 0x55, 0x13, 0x23, 0x80, 0x46, 0x4a, 0x68, 0xf4, 0x4c, 0x7b, 0x13, 0x06, 0xb1, 0x0a, 0x1e, 0x03, 0x92, 0x8c, 0x36, 0x47, 0x61, 0xdb, 0x0b, 0x1f, 0x00, 0xcc, 0x4f, 0x82, 0x10, 0x08, 0xc4, 0x65, 0x6b, 0x69, 0xe5, 0x23, 0x18, 0x77, 0x13, 0x4f, 0x09, 0x3e, 0x43, 0xff, 0x23, 0x07, 0x61, 0x69, 0xd6, 0x63, 0x6b, 0x20, 0x38, 0x73, 0x4c, 0x23, 0x23, 0x82, 0x2b, 0x7d, 0x79, 0xb0, 0x10, 0x1e, 0x4e, 0x69, 0xd5, 0x2b, 0x5d, 0x72, 0xf4, 0x3a, 0x11, 0x5d, 0x4a, 0xff, 0xd0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; +static char midi2[] = {0x00, 0x74, 0x62, 0xc0, 0xd2, 0x07, 0xcf, 0x07, 0xcf, 0x0b, 0x8e, 0x54, 0xe9, 0xd5, 0x09, 0x47, 0x00, 0xc1, 0x06, 0x7a, 0x30, 0x77, 0x09, 0x01, 0xb1, 0x44, 0x6f, 0x81, 0xe1, 0x2c, 0x5f, 0x06, 0x4a, 0xc6, 0x8a, 0x67, 0x4c, 0x91, 0x62, 0x0c, 0x73, 0x87, 0xc1, 0x58, 0x17, 0x00, 0xde, 0x12, 0xde, 0x76, 0x4a, 0xb0, 0x0b, 0x52, 0x72, 0x11, 0x23, 0x36, 0x13, 0x01, 0xf9, 0x7b, 0x96, 0x70, 0xd9, 0x60, 0x5f, 0x49, 0x68, 0x30, 0x7b, 0x58, 0x00, 0x91, 0x13, 0x32, 0x87, 0x76, 0xfd, 0x0b, 0x17, 0x48, 0xfa, 0xdf, 0x2f, 0x4e, 0x05, 0xb0, 0x4c, 0x77, 0x81, 0xe0, 0x08, 0x78, 0x13, 0x4d, 0xd9, 0x8a, 0x67, 0x4c, 0x91, 0x5d, 0x17, 0x60, 0x87, 0xc1, 0x43, 0x17, 0x00, 0xd6, 0x38, 0xde, 0x76, 0x41, 0xb1, 0x0b, 0x54, 0x63, 0x10, 0x2b, 0x1c, 0x06, 0x05, 0xf8, 0x6a, 0x9c, 0x70, 0xd8, 0x4c, 0x77, 0x54, 0x5e, 0x30, 0x7b, 0x50, 0x00, 0x91, 0x19, 0x01, 0x87, 0x76, 0xf2, 0x0b, 0x17, 0x40, 0xcd, 0xd8, 0x2f, 0x46, 0x06, 0xb1, 0x4c, 0x4d, 0x81, 0xe1, 0x1f, 0x5f, 0x06, 0x46, 0xe9, 0x8a, 0x6d, 0x43, 0x90, 0x53, 0x35, 0x44, 0x80, 0xc1, 0x4b, 0x17, 0x00, 0xad, 0x02, 0xde, 0x76, 0x3a, 0xb1, 0x0b, 0xe8, 0x2f, 0x91, 0x1b, 0x0b, 0x74, 0x6d, 0xb1, 0x0b, 0x16, 0xb6, 0x91, 0x94, 0x0a, 0x06, 0xb4, 0xb7, 0x51, 0x13, 0x91, 0xf3, 0x10, 0x23, 0x70, 0x02, 0xb1, 0x69, 0x48, 0x50, 0xf3, 0x54, 0x5f, 0x67, 0x59, 0xe1, 0x6a, 0x17, 0x00, 0xf1, 0x0c, 0x0f, 0x66, 0x06, 0xb1, 0x54, 0x48, 0x50, 0xce, 0x52, 0x5f, 0x58, 0x5b, 0xe0, 0x55, 0x1c, 0x00, 0xcd, 0x13, 0x22, 0x4e, 0x02, 0xb1, 0x57, 0x48, 0x50, 0xcd, 0x51, 0x5f, 0x5d, 0x59, 0xe1, 0x50, 0x17, 0x00, 0xcb, 0x0f, 0x0f, 0x5c, 0x06, 0xb1, 0x52, 0x48, 0x50, 0xc8, 0x4f, 0x5f, 0x5e, 0x5b, 0xe0, 0x53, 0x1c, 0x00, 0xc7, 0x17, 0x20, 0x44, 0x02, 0xb1, 0x5d, 0x48, 0x50, 0xc7, 0x4e, 0x5f, 0x53, 0x59, 0xe1, 0x5e, 0x17, 0x0f, 0xc5, 0x12, 0x0f, 0x52, 0x06, 0xb1, 0x58, 0x48, 0x50, 0xc2, 0x4c, 0x5f, 0x54, 0x5b, 0xe0, 0x59, 0x1b, 0x00, 0xc1, 0x10, 0x3e, 0x42, 0x02, 0xb1, 0x5b, 0x48, 0x50, 0xc1, 0x4b, 0x5f, 0x49, 0x59, 0xe1, 0x44, 0x17, 0x00, 0xdf, 0x15, 0x0f, 0x48, 0x06, 0xb1, 0x46, 0x48, 0x50, 0xdc, 0x49, 0x5f, 0x4a, 0x5b, 0xe0, 0x47, 0x1b, 0x00, 0xdb, 0x13, 0x3d, 0x58, 0x02, 0xb1, 0x41, 0x48, 0x50, 0xdb, 0x48, 0x5f, 0x4f, 0x59, 0xe1, 0x42, 0x17, 0x00, 0xd9, 0x18, 0x0f, 0x4e, 0x06, 0xb1, 0x4c, 0x48, 0x50, 0xd6, 0x46, 0x5f, 0x40, 0x5b, 0xe0, 0x4d, 0x1a, 0x00, 0xd5, 0x17, 0x3b, 0x56, 0x02, 0xb1, 0x4f, 0x48, 0x50, 0xd5, 0x45, 0x5f, 0x45, 0x59, 0xe1, 0x48, 0x17, 0x00, 0xd3, 0x1b, 0x0f, 0x44, 0x06, 0xb1, 0x4a, 0x48, 0x50, 0xd0, 0x43, 0x5f, 0x46, 0x5b, 0xe0, 0x4b, 0x1a, 0x00, 0xaf, 0x18, 0x39, 0x2c, 0x02, 0xb1, 0x35, 0x48, 0x50, 0xaf, 0x42, 0x5f, 0x3b, 0x59, 0xe1, 0x36, 0x17, 0x00, 0xad, 0x1e, 0x0f, 0x3a, 0x06, 0xb1, 0x30, 0x48, 0x50, 0xaa, 0x40, 0x5f, 0x3c, 0x64, 0xe0, 0x31, 0x1a, 0x00, 0xa9, 0x2c, 0x38, 0x2a, 0x02, 0xb1, 0x33, 0x77, 0x50, 0xa9, 0x3f, 0x5f, 0x31, 0x66, 0xe1, 0x3c, 0x17, 0x00, 0xa7, 0x5e, 0x0f, 0x30, 0x06, 0xb1, 0x3e, 0x77, 0x50, 0xa4, 0x3d, 0x5f, 0x32, 0x64, 0xe0, 0x3f, 0x19, 0x00, 0xa3, 0x28, 0x36, 0x20, 0x02, 0xb1, 0x39, 0x77, 0x50, 0xa3, 0x3c, 0x5f, 0x37, 0x66, 0xe1, 0x3a, 0x17, 0x00, 0xa1, 0x5a, 0x1f, 0x29, 0x67, 0xa1}; + +/* SPMA100B driver */ +/* XXX: WARNING! Just guessed! Don't rely on anything! */ + +static void spma100_volume(uint8_t vol1, uint8_t vol2, uint8_t vol3, uint8_t vol4) +{ + /* + * Volume registers + * VDS also OK for VDD=2.8V and SPVDD=3.3V + */ + spma100_regwrite(0xe3, vol1); // MIDI or Master + spma100_regwrite(0xe4, vol2); // PCM??? + spma100_regwrite(0xe5, vol3); // PCM??? + spma100_regwrite(0xe6, vol4); // opposite of 0xe3 +} + +static void spma100_standby(void) +{ + /* Volume: Mute */ + spma100_volume(0, 0, 0, 0); + + spma100_regwrite(0xe2, 0x00); + spma100_regwrite(0xe2, 0x01); + spma100_regwrite(0xe1, 0xff); + spma100_regwrite(0xe2, 0x00); + spma100_regwrite(0xe2, 0x01); + spma100_regwrite(0xf2, 0x04); +} + +static void spma100_start(void) +{ + /* Toggle something. Power? */ + spma100_regwrite(0xe2, 0x00); + spma100_regwrite(0xe2, 0x01); + + spma100_regwrite(0xff, 0x07); + spma100_regwrite(0xe9, 0x00); + spma100_regwrite(0xf2, 0x00); + + /* Volume: Mute */ + spma100_volume(0, 0, 0, 0); + + /* Power-up sequence/disable power-downs. Clicks otherwise */ + spma100_regwrite(0xe1, 0x7e); + spma100_regwrite(0xe1, 0x1e); + spma100_regwrite(0xe1, 0x04); + spma100_regwrite(0xe1, 0x00); + + /* + * PLL settings + * With OKI's table 8, this would be 13*34/10 = 44.2MHz + * -> 0.2% error for 44.1kHz * 1000 cycles/sample + * XXX: why twice!? + */ + spma100_regwrite(0xe7, 0x22); + spma100_regwrite(0xe8, 0x09); + spma100_regwrite(0xf3, 0x22); + spma100_regwrite(0xf4, 0x09); + + /* + * Would be transition from MUTE to 0dB for W56964 + */ + spma100_volume(0, 0, 0, 0); + spma100_volume(0x1f, 0x1f, 0x1f, 0x10); + + spma100_regwrite(0xdb, 0x08); + spma100_regwrite(0xdc, 0x00); + spma100_regwrite(0xde, 0x08); + spma100_regwrite(0xdf, 0x00); +} + +static void spma100_senddata(char *data, int length) +{ + int i; + for(i=0; i Hi all, JFYI: For a couple of days, *.osmocom.org is reachable via IPv6. I've had native IPv6 at my co-located servers for more than 10 years, but somehow never configured it for the virtual machines like *.osmocom.org - this is now fixed. If you encounter any difficulties, please let me know. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun May 8 12:20:41 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 8 May 2011 14:20:41 +0200 Subject: [ANN] libosmocore stable API/ABI Message-ID: <20110508122041.GI16877@prithivi.gnumonks.org> Hi all! I think now that the namespace issues in libosmocore have been resolved, we seriously have to think of maintaining a stable API and ABI. This allows us to have truly independent library and application releases, and the dynamic linker library versioning support should ensure compatibility. So please think twice about any modifying libosmocore. It is safe to add new functions, but we cannot change the prototypes (number of arguments) for existing functions. As soon as new functions are introduced, we should increment the library interface number. For more information, see http://www.gnu.org/software/libtool/manual/libtool.html#Versioning especially the rules in Chapter 7.3: # If the library source code has changed at all since the last update, then increment revision (?c:r:a? becomes ?c:r+1:a?). # If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. # If any interfaces have been added since the last public release, then increment age. # If any interfaces have been removed or changed since the last public release, then set age to 0. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pablo at gnumonks.org Sun May 8 16:57:37 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 08 May 2011 18:57:37 +0200 Subject: [ANN] libosmocore stable API/ABI In-Reply-To: <20110508122041.GI16877@prithivi.gnumonks.org> References: <20110508122041.GI16877@prithivi.gnumonks.org> Message-ID: <4DC6CB81.2040000@gnumonks.org> On 08/05/11 14:20, Harald Welte wrote: > Hi all! > > I think now that the namespace issues in libosmocore have been resolved, > we seriously have to think of maintaining a stable API and ABI. This > allows us to have truly independent library and application releases, > and the dynamic linker library versioning support should ensure > compatibility. Would it be worth if we make opaque declaration of some structures opaque? e.g. struct osmo_timer_list in the header file, and the real declaration in Encapsulation is good to avoid breaking backward compatibility. Not sure if we expect that this structure would ever change. Let me know if I'm being too conservative :-). > So please think twice about any modifying libosmocore. It is safe to > add new functions, but we cannot change the prototypes (number of > arguments) for existing functions. > > As soon as new functions are introduced, we should increment the library > interface number. > > For more information, see > http://www.gnu.org/software/libtool/manual/libtool.html#Versioning > especially the rules in Chapter 7.3: > > # If the library source code has changed at all since the last update, > then increment revision (?c:r:a? becomes ?c:r+1:a?). > # If any interfaces have been added, removed, or changed since the last > update, increment current, and set revision to 0. > # If any interfaces have been added since the last public release, then > increment age. > # If any interfaces have been removed or changed since the last public > release, then set age to 0. I think that we should also use a map file [1] and the EXPORT_SYMBOL declaration [2]. I can make a patch to support this. These references point to libmnl as one example of mine: [1] http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libmnl.git;a=blob;f=src/libmnl.map;h=3147ae099f35b72a86bb74ffb19f9214bf187728;hb=HEAD [2] http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libmnl.git;a=blob;f=src/internal.h;h=3a88d1a1f7d8b00c73a9e77524796811df7e9653;hb=HEAD From laforge at gnumonks.org Sun May 8 17:42:55 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 8 May 2011 19:42:55 +0200 Subject: [ANN] libosmocore stable API/ABI In-Reply-To: <4DC6CB81.2040000@gnumonks.org> References: <20110508122041.GI16877@prithivi.gnumonks.org> <4DC6CB81.2040000@gnumonks.org> Message-ID: <20110508174255.GA11457@prithivi.gnumonks.org> Hi Pablo, On Sun, May 08, 2011 at 06:57:37PM +0200, Pablo Neira Ayuso wrote: > > I think now that the namespace issues in libosmocore have been resolved, > > we seriously have to think of maintaining a stable API and ABI. This > > allows us to have truly independent library and application releases, > > and the dynamic linker library versioning support should ensure > > compatibility. > > Would it be worth if we make opaque declaration of some structures > opaque? e.g. struct osmo_timer_list in the header file, and the real > declaration in I think this would be too much at this point. I also think we don't have any 'illegitimate' use of the structures, and we are only using the libraries from a couple of programs that all come 'from the same family' > I think that we should also use a map file [1] and the EXPORT_SYMBOL > declaration [2]. same here. I think for now it only creates additional work without much benefit from it. The EXPORT_SYMBOL stuff only becomes interesting once we have calls to private functions between multiple .o files. Rigth now off my head they only case where this would make practical sense is for libosmovty, where we have lots of buffer.c and cmd.c calls from within vty.c which shouldn't be public at all. I would definitely welcome a patch to that regard. Rather than spending time on map files and private/public header files, I would be more open to some kerneldoc or doxygen comments in the code, in order to generate some official libosmocore API documentation. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gyoutubeg at yahoo.com.br Mon May 9 11:40:07 2011 From: gyoutubeg at yahoo.com.br (Gerard) Date: Mon, 9 May 2011 11:40:07 +0000 (UTC) Subject: GSM specs doubt Message-ID: Hi list, while studing burst_ind (I know that burst_ind must be used in a own controlled network) i see that one SDCCH for a specific operator has been shared by more than one MS (different TMSIs), some MS use for SMS other use for calls. Is that an interpratation error (due the fact of using burst_ind in real networks) or that could be possible? i didn't find explanations on sepcs. TIA From laforge at gnumonks.org Mon May 9 13:16:33 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 9 May 2011 15:16:33 +0200 Subject: GSM specs doubt In-Reply-To: References: Message-ID: <20110509131633.GN21397@prithivi.gnumonks.org> On Mon, May 09, 2011 at 11:40:07AM +0000, Gerard wrote: > Hi list, > while studing burst_ind (I know that burst_ind must be used in a own controlled > network) i see that one SDCCH for a specific operator has been shared by more > than one MS (different TMSIs), some MS use for SMS other use for calls. Is that > an interpratation error (due the fact of using burst_ind in real networks) or > that could be possible? i didn't find explanations on sepcs. It's called SDCCH/8 or SDCCH/4 since one on-air timeslot (physical channel) is used to generate 8 (or 4, respectively) SDCCH logical channels. in GSM, everything is TDMA. Take your time to really understand the TDMA hierarchy. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gianni at scaramanga.co.uk Wed May 11 00:12:28 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Wed, 11 May 2011 01:12:28 +0100 Subject: calypso SIM driver on c139 (also: l1ctl SIM APDU) Message-ID: <1305072748.25954.4.camel@deckard> The SIM and the SIM reader in the phone and the mechanical contact between them are definitely working because the SIM can be accessed from the motorola firmware, from another phone and from a PC smartcard reader with no PIN or anything. However, under simtest firmware no data is received by the phone, even the ATR is zero bytes... Anybody had this problem? Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? How are people making calls without a SIM? :P Gianni ----------------SIMTEST----8<----------------- Initializing driver: SIM: Registering interrupt handler for simcard-interface ====================== CALYPSO SIM REGISTER DUMP ===================== Reg_sim_cmd register (R/W) - FFFE:0000 |-REG_SIM_CMD = 0000 | |-REG_SIM_CMD_CMDCARDRST = 0 ==> SIM card reset sequence disabled. | |-REG_SIM_CMD_CMDIFRST = 0 | |-REG_SIM_CMD_CMDSTOP = 0 | |-REG_SIM_CMD_CMDSTART = 0 | |-REG_SIM_CMD_MODULE_CLK_EN = 0 ==> Clock of the module disabled. |-REG_SIM_STAT = 000b | |-REG_SIM_STAT_STATNOCARD = 1 ==> No card! | |-REG_SIM_STAT_STATTXPAR = 1 ==> Parity ok! | |-REG_SIM_STAT_STATFIFOFULL = 0 | |-REG_SIM_STAT_STATFIFOEMPTY = 1 ==> Fifo empty! |-REG_SIM_CONF1 = 000c | |-REG_SIM_CONF1_CONFCHKPAR = 0 ==> Parity check on reception disabled. | |-REG_SIM_CONF1_CONFCODCONV = 0 ==> Coding convention is direct (normal). | |-REG_SIM_CONF1_CONFTXRX = 1 ==> SIO line direction is in transmit mode. | |-REG_SIM_CONF1_CONFSCLKEN = 1 ==> SIM clock in normal mode. | |-REG_SIM_CONF1_reserved = 0 ==> ETU period is CONFETUPERIOD. | |-REG_SIM_CONF1_CONFSCLKDIV = 0 ==> SIM clock frequency is 13/4 Mhz. | |-REG_SIM_CONF1_CONFSCLKLEV = 0 ==> SIM clock idle level is low. | |-REG_SIM_CONF1_CONFETUPERIOD = 0 ==> ETU period is 372/8*1/Fsclk. | |-REG_SIM_CONF1_CONFBYPASS = 0 ==> Hardware timers and start and stop sequences are normal. | |-REG_SIM_CONF1_CONFSVCCLEV = 0 ==> SVCC Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFSRSTLEV = 0 ==> SRST Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFTRIG = 0x0 (FIFO trigger level) | |-REG_SIM_CONF1_CONFSIOLOW = 0 |-REG_SIM_CONF2 = 0940 | |-REG_SIM_CONF2_CONFTFSIM = 0x0 (time delay for filtering of SIM_CD) | |-REG_SIM_CONF2_CONFTDSIM = 0x4 (time delay for contact activation/deactivation) | |-REG_SIM_CONF2_CONFWAITI = 0x9 (CONFWAITI overflow wait time between two received chars) |-REG_SIM_IT = 0000 | |-REG_SIM_IT_SIM_NATR = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_WT = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_OV = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_TX = 0 ==> On write access to REG_SIM_DTX or on switching | | from transmit to receive mode (CONFTXRX bit) | |-REG_SIM_IT_SIM_RX = 0 ==> On read access to REG_SIM_DRX. |-REG_SIM_DRX = 0100 | |-REG_SIM_DRX_SIM_DRX = 0x0 (next data byte in FIFO available for reading) | |-REG_SIM_DRX_STATRXPAR = 1 ==> Parity Ok. |-REG_SIM_DTX = 00 (next data byte to be transmitted) |-REG_SIM_MASKIT = 003f | |-REG_SIM_MASKIT_MASK_SIM_NATR = 1 ==> No-answer-to-reset interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_WT = 1 ==> Character wait-time overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_OV = 1 ==> Receive overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_TX = 1 ==> Waiting characters to be transmit interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_RX = 1 ==> Waiting characters to be read interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_CD = 1 ==> SIM card insertion/extraction interrupt is masked. |-REG_SIM_IT_CD = fffe0010 |-REG_SIM_IT_CD_IT_CD = 0 ==> SIM card insertion/extraction interrupt is unmasked. Power up simcard: * Power enabled! * Clock enabled! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) Reset simcard: * Reset pulled down! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! SIM-T0: Transceiving APDU-Header: (a0 c0 00 00 0f) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 4: Input / No output (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Incorrect or missing answer -- aborting! e0 73 d7 b9 ae ea bf 7e f7 3b 7f 6f 32 fe 25 (15 bytes) Test Phase 1: Testing bare sim commands... * Testing SELECT: Selecting MF SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! ==> Status word: ffff * Testing SELECT: Selecting DF_GSM SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... At this point it hangs "forever" - well at least half hour. From gianni at scaramanga.co.uk Wed May 11 00:39:18 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Wed, 11 May 2011 01:39:18 +0100 Subject: calypso SIM driver on c139 (also: l1ctl SIM APDU) In-Reply-To: <1305072748.25954.4.camel@deckard> References: <1305072748.25954.4.camel@deckard> Message-ID: <1305074358.25954.7.camel@deckard> On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote: > The SIM and the SIM reader in the phone and the mechanical contact > between them are definitely working because the SIM can be accessed from > the motorola firmware, from another phone and from a PC smartcard reader > with no PIN or anything. > > However, under simtest firmware no data is received by the phone, even > the ATR is zero bytes... > > Anybody had this problem? > > Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? > How are people making calls without a SIM? :P On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote > If you wait a bit you will get code for the second > suggestion. We currently have a working version that > forwards the apdu to a local client transforming this into > SAP and speaking with a SAP server that uses pcsc to talk to > a SIM card in an external SIM reader. My goal though is to > transform this into a complete SAP client in > sap_interface.c, I will work on that now... Actually, how far have you got with this? Turns out I had the same idea as you except I was going to use a unix socket with no protocol (ie. no SAP) to just communicate with my ccid-utils driver to talk to the SIM. Gianni From gianni at scaramanga.co.uk Wed May 11 02:58:41 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Wed, 11 May 2011 03:58:41 +0100 Subject: calypso SIM driver on c139 (also: l1ctl SIM APDU) In-Reply-To: <1305074358.25954.7.camel@deckard> References: <1305072748.25954.4.camel@deckard> <1305074358.25954.7.camel@deckard> Message-ID: <1305082721.25954.9.camel@deckard> On Wed, 2011-05-11 at 01:39 +0100, Gianni Tedesco wrote: > On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote: > > The SIM and the SIM reader in the phone and the mechanical contact > > between them are definitely working because the SIM can be accessed from > > the motorola firmware, from another phone and from a PC smartcard reader > > with no PIN or anything. > > > > However, under simtest firmware no data is received by the phone, even > > the ATR is zero bytes... > > > > Anybody had this problem? > > > > Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? > > How are people making calls without a SIM? :P > > On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote > > If you wait a bit you will get code for the second > > suggestion. We currently have a working version that > > forwards the apdu to a local client transforming this into > > SAP and speaking with a SAP server that uses pcsc to talk to > > a SIM card in an external SIM reader. My goal though is to > > transform this into a complete SAP client in > > sap_interface.c, I will work on that now... > > Actually, how far have you got with this? Turns out I had the same idea > as you except I was going to use a unix socket with no protocol (ie. no > SAP) to just communicate with my ccid-utils driver to talk to the SIM. I did just that using SEQPACKET unix sockets. Patch attached, sample simctl is at https://github.com/giannitedesco/ccid-utils/tree/simctl I was able to register a network and place a voice call with this. Gianni -------------- next part -------------- A non-text attachment was scrubbed... Name: simctl.diff Type: text/x-patch Size: 11918 bytes Desc: not available URL: From osmocom at ngolde.de Wed May 11 12:12:08 2011 From: osmocom at ngolde.de (osmocom at ngolde.de) Date: Wed, 11 May 2011 14:12:08 +0200 Subject: calypso SIM driver on c139 (also: l1ctl SIM APDU) In-Reply-To: <1305074358.25954.7.camel@deckard> References: <1305072748.25954.4.camel@deckard> <1305074358.25954.7.camel@deckard> Message-ID: <20110511121208.GA2902@segfault.binarybase.org> Hi, * Gianni Tedesco [2011-05-11 13:49]: > On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote: [...] > On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote > > If you wait a bit you will get code for the second > > suggestion. We currently have a working version that > > forwards the apdu to a local client transforming this into > > SAP and speaking with a SAP server that uses pcsc to talk to > > a SIM card in an external SIM reader. My goal though is to > > transform this into a complete SAP client in > > sap_interface.c, I will work on that now... > > Actually, how far have you got with this? Turns out I had the same idea > as you except I was going to use a unix socket with no protocol (ie. no > SAP) to just communicate with my ccid-utils driver to talk to the SIM. That's what I did before but as sap_interface.c already existed and there is a sap server with pcsc in the softsim repository I wanted a real SAP client to use it directly. I've got a working prototype which needs some cleaning. I'll send a patch for this to the list in the next days. Cheers Nico From gianni at scaramanga.co.uk Wed May 11 21:53:03 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Wed, 11 May 2011 22:53:03 +0100 Subject: calypso SIM driver on c139 (also: l1ctl SIM APDU) In-Reply-To: <20110511121208.GA2902@segfault.binarybase.org> References: <1305072748.25954.4.camel@deckard> <1305074358.25954.7.camel@deckard> <20110511121208.GA2902@segfault.binarybase.org> Message-ID: <1305150783.2213.5.camel@deckard> On Wed, 2011-05-11 at 14:12 +0200, osmocom at ngolde.de wrote: > Hi, > * Gianni Tedesco [2011-05-11 13:49]: > > On Wed, 2011-05-11 at 01:12 +0100, Gianni Tedesco wrote: > [...] > > On Mon May 9 12:12:49 CEST 2011, Nico Golde wrote > > > If you wait a bit you will get code for the second > > > suggestion. We currently have a working version that > > > forwards the apdu to a local client transforming this into > > > SAP and speaking with a SAP server that uses pcsc to talk to > > > a SIM card in an external SIM reader. My goal though is to > > > transform this into a complete SAP client in > > > sap_interface.c, I will work on that now... > > > > Actually, how far have you got with this? Turns out I had the same idea > > as you except I was going to use a unix socket with no protocol (ie. no > > SAP) to just communicate with my ccid-utils driver to talk to the SIM. > > That's what I did before but as sap_interface.c already > existed and there is a sap server with pcsc in the softsim > repository I wanted a real SAP client to use it directly. > I've got a working prototype which needs some cleaning. I'll > send a patch for this to the list in the next days. If you can get the command-line configuration of this working then I could always resubmit my patch on top of it as a "naked-protocol" option for the SAP module or something like that? Gianni From osmocom at ngolde.de Mon May 23 07:29:57 2011 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 23 May 2011 09:29:57 +0200 Subject: [PATCH] SAP client In-Reply-To: <20110511121208.GA2902@segfault.binarybase.org> References: <1305072748.25954.4.camel@deckard> <1305074358.25954.7.camel@deckard> <20110511121208.GA2902@segfault.binarybase.org> Message-ID: <20110523072957.GA2139@segfault.binarybase.org> I have now committed the attached patch to remotes/origin/nion/sap. I've used this so far in combination with the sap server in the softsim repository in order to not use the sim driver. The patch removes the pre-defined sap socket path and additionally to the already existing config option introduces a new vty command to set the socket before issuing sap reader ms... Andreas told me that the initial plan was to implement the sap server in osmocom as well and also speak to the sim into the phone over sap. I haven't implemented this, however I'm also not sure how much sense this makes given the additional complexity for practically no gain (or I miss something). Comments welcome... Cheers Nico From osmocom at ngolde.de Mon May 23 22:47:25 2011 From: osmocom at ngolde.de (Nico Golde) Date: Tue, 24 May 2011 00:47:25 +0200 Subject: [PATCH] SAP client In-Reply-To: <20110523072957.GA2139@segfault.binarybase.org> References: <1305072748.25954.4.camel@deckard> <1305074358.25954.7.camel@deckard> <20110511121208.GA2902@segfault.binarybase.org> <20110523072957.GA2139@segfault.binarybase.org> Message-ID: <20110523224725.GA3194@segfault.binarybase.org> Hi, * Nico Golde [2011-05-23 11:18]: > I have now committed the attached patch to remotes/origin/nion/sap. Forgot to add the patch. Adding again for reference in case the remote branch gets wiped at some point. Cheers Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: sap.patch Type: text/x-diff Size: 25276 bytes Desc: not available URL: From gianni at scaramanga.co.uk Thu May 12 02:27:15 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Thu, 12 May 2011 03:27:15 +0100 Subject: [PATCH]: Implement SMS decoding Message-ID: <1305167235.2213.8.camel@deckard> Hi, Attached patch implements SMS decoding. Right now it just logs it all to DMM (when I tried DSMS I didn't get any output?!). What remains is to plumb this through to mobile so that the messages can be displayed over a vty and also to send a response other than GSM48_REJECT_MSG_TYPE_NOT_IMPLEMENTED - but I'm not sure what needs to happen here. Is anyone else working in this area? Gianni commit a244cccb6f7600cb867e4949926cc7d877b58f31 Author: Gianni Tedesco Date: Thu May 12 03:24:19 2011 +0100 Implement SMS decoding diff --git a/src/host/layer23/src/mobile/Makefile.am b/src/host/layer23/src/mobile/Makefile.am index fb0423e..60e8d23 100644 --- a/src/host/layer23/src/mobile/Makefile.am +++ b/src/host/layer23/src/mobile/Makefile.am @@ -4,7 +4,7 @@ LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOVTY_LIBS) $(LIBOSMOG noinst_LIBRARIES = libmobile.a libmobile_a_SOURCES = gsm322.c gsm48_cc.c gsm48_mm.c gsm48_rr.c \ - mnccms.c settings.c subscriber.c support.c \ + gsm48_sms.c mnccms.c settings.c subscriber.c support.c \ transaction.c vty_interface.c bin_PROGRAMS = mobile diff --git a/src/host/layer23/src/mobile/gsm48_mm.c b/src/host/layer23/src/mobile/gsm48_mm.c index bf5bbc2..84069f3 100644 --- a/src/host/layer23/src/mobile/gsm48_mm.c +++ b/src/host/layer23/src/mobile/gsm48_mm.c @@ -36,6 +36,7 @@ #include #include #include +#include #include extern void *l23_ctx; @@ -737,10 +738,10 @@ int gsm48_mmxx_dequeue(struct osmocom_ms *ms) case GSM48_MMSS_CLASS: gsm48_rcv_ss(ms, msg); break; +#endif case GSM48_MMSMS_CLASS: gsm48_rcv_sms(ms, msg); break; -#endif } msgb_free(msg); work = 1; /* work done */ @@ -3847,9 +3848,10 @@ static int gsm48_mm_data_ind(struct osmocom_ms *ms, struct msgb *msg) case GSM48_PDISC_NC_SS: return gsm48_rcv_ss(ms, msg); - case GSM48_PDISC_SMS: - return gsm48_rcv_sms(ms, msg); #endif + case GSM48_PDISC_SMS: + LOGP(DMM, LOGL_NOTICE, "SMS PDISC = 0x%.2x\n", GSM48_PDISC_SMS); + gsm48_rcv_sms(ms, msg); default: LOGP(DMM, LOGL_NOTICE, "Protocol type 0x%02x unsupported.\n", diff --git a/src/host/layer23/src/mobile/gsm48_sms.c b/src/host/layer23/src/mobile/gsm48_sms.c new file mode 100644 index 0000000..63b1965 --- /dev/null +++ b/src/host/layer23/src/mobile/gsm48_sms.c @@ -0,0 +1,306 @@ +/* + * (C) 2010 by Andreas Eversberg + * (C) 2011 by Gianni Tedesco + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#define CP_DATA 1 + +#define RP_DATA 1 +#define RP_ACK 3 +#define RP_ERROR 5 + +#define TP_MTI_MASK 3 +#define SMS_DELIVER 0 +#define SMS_SUBMIT_REPORT 1 +#define SMS_STATUS_REPORT 2 + +#define TP_RP 0x80 +#define TP_UDHI 0x40 +#define TP_SRI 0x20 +#define TP_MMS 0x04 + +static void decode_7bit(const uint8_t *inp, size_t octets, size_t len) +{ + uint8_t out[len + 1]; + unsigned int i; + + for(i = 0; i <= len; i++) { + int ipos = i - (i >> 3); + int offset = (i & 0x7); + + out[i] = (inp[ipos] & (0x7F >> offset)) << offset; + if( 0 == offset ) + continue; + + out[i] |= (inp[ipos - 1] & + (0x7F << (8 - offset)) & 0xFF) >> (8 - offset); + } + + out[len] = '\0'; + LOGP(DMM, LOGL_NOTICE, "SMS: \"%s\"\n", out); +} + +static uint8_t hi_nibble(uint8_t byte) +{ + return byte >> 4; +} + +static uint8_t lo_nibble(uint8_t byte) +{ + return byte & 0xf; +} + +static int parse_address(struct msgb *msg, int rp, const char *name) +{ + uint8_t len, type; + + if ( !msg->len ) + return -EPROTO; + + len = msgb_get_u8(msg); + if ( !len ) + return 0; + + type = msgb_get_u8(msg); + + if ( rp ) { + /* for RP address, len is in bytes including type field */ + len = len - 1; + }else{ + /* TP address is in BCD digits, not including type field */ + len = len / 2; + } + + if ( msg->len < len ) + return -EPROTO; + + LOGP(DMM, LOGL_NOTICE, "%s: type=0x%.2x %s\n", + name, type, hexdump(msg->data, len)); + + msgb_pull(msg, len); + return 0; +} + +static int parse_timestamp(struct msgb *msg, const char *name) +{ + if ( msg->len < 7 ) + return -EPROTO; + LOGP(DMM, LOGL_NOTICE, + "%s: 20%1x%1x-%1x%1x-%1x%1x %1x%1x:%1x%1x:%1x%1x\n", + name, + lo_nibble(msg->data[0]), + hi_nibble(msg->data[0]), + lo_nibble(msg->data[1]), + hi_nibble(msg->data[1]), + lo_nibble(msg->data[2]), + hi_nibble(msg->data[2]), + lo_nibble(msg->data[3]), + hi_nibble(msg->data[3]), + lo_nibble(msg->data[4]), + hi_nibble(msg->data[4]), + lo_nibble(msg->data[5]), + hi_nibble(msg->data[5])); + msgb_pull(msg, 7); + return 0; +} +static int sms_deliver(struct osmocom_ms *ms, struct msgb *msg, uint8_t b) +{ + uint8_t tp_pid, tp_dcs, tp_udlen; + int rc; + + if ( !(b & TP_MMS) ) + LOGP(DMM, LOGL_NOTICE, "SMS-DELIVER: More messages to send.\n"); + + rc = parse_address(msg, 0, "TP-Originating"); + if ( rc ) + return -EPROTO; + + if ( msg->len < 2 ) + return -EPROTO; + + tp_pid = msgb_get_u8(msg); + tp_dcs = msgb_get_u8(msg); + LOGP(DMM, LOGL_NOTICE, "TP-PID: 0x%.2x\n", tp_pid); + LOGP(DMM, LOGL_NOTICE, "TP-DCS: 0x%.2x\n", tp_dcs); + + rc = parse_timestamp(msg, "TP-Service-Center-Time-Stamp"); + if ( rc ) + return -EPROTO; + + if ( !msg->len ) + return -EPROTO; + tp_udlen = msgb_get_u8(msg); + + /* check for unknown data coding scheme */ + if (tp_dcs) + return 0; + + decode_7bit(msg->data, msg->len, tp_udlen); + return 0; +} + +static int sms_tpdu_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t tp_mti; + + if ( !msg->len ) + return 0; + tp_mti = msgb_get_u8(msg); + + switch(tp_mti & TP_MTI_MASK) { + case SMS_DELIVER: + return sms_deliver(ms, msg, tp_mti); + case SMS_SUBMIT_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-SUBMIT-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + case SMS_STATUS_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-STATUS-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + default: + LOGP(DMM, LOGL_NOTICE, "Reserved MTI: 0x%.2x\n", + tp_mti); + return -EPROTO; + } + + return 0; +} + +static int rp_data_decode(struct osmocom_ms *ms, struct msgb *msg, uint8_t ref) +{ + static const char * const str[2] = {"RP-Origination", "RP-Destination"}; + unsigned int i; + uint8_t tpdu_len; + + LOGP(DMM, LOGL_NOTICE, "Received RP-DATA: ref %d\n", ref); + + for(i = 0; i < 2; i++) { + int rc; + + rc = parse_address(msg, 1, str[i]); + if ( rc ) + return -EPROTO; + } + + if ( !msg->len ) + return -EPROTO; + tpdu_len = msgb_get_u8(msg); + if ( tpdu_len < msg->len ) + return -EPROTO; + if ( tpdu_len < msg->len ) { + LOGP(DMM, LOGL_NOTICE, "RP-DATA: %u trailing bytes: %s\n", + msg->len - tpdu_len, + hexdump(msg->data + tpdu_len, msg->len - tpdu_len)); + msg->len = tpdu_len; + } + + /* TODO: pass in reference, and src/dst addresses */ + return sms_tpdu_decode(ms, msg); +} + +static int rp_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t rp_mt, rp_ref; + + if ( msg->len < 2 ) + return -EPROTO; + + rp_mt = msgb_get_u8(msg); + rp_ref = msgb_get_u8(msg); + + switch(rp_mt) { + case RP_DATA: + return rp_data_decode(ms, msg, rp_ref); + case RP_ACK: + LOGP(DMM, LOGL_NOTICE, "Received RP-ACK: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + case RP_ERROR: + LOGP(DMM, LOGL_NOTICE, "Received RP-ERROR: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + default: + LOGP(DMM, LOGL_NOTICE, "Bad RP Message-type: 0x%.2x\n", rp_mt); + return -ENOTSUP; + } + + return 0; +} + +static int cp_data(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t len; + + if ( !msg->len ) + return -EPROTO; + len = msgb_get_u8(msg); + if ( len != msg->len ) { + LOGP(DMM, LOGL_NOTICE, "CP-DATA: size mismatch " + "%u != %u bytes\n", len, msg->len); + }else{ + LOGP(DMM, LOGL_NOTICE, "CP-DATA: %u bytes\n", len); + } + + return rp_decode(ms, msg); +} + +int gsm48_rcv_sms(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t cp_type; + + LOGP(DMM, LOGL_NOTICE, "Received SMS: %s\n", + hexdump(msg->data, msg->len)); + + if ( msg->len < 2) + return -EPROTO; + + msgb_pull(msg, 1); /* protocol discriminator */ + cp_type = msgb_get_u8(msg); + + switch(cp_type) { + case CP_DATA: + return cp_data(ms, msg); + default: + LOGP(DMM, LOGL_NOTICE, "Unknown SMS type: 0x%.2x\n", cp_type); + return 0; + } + + return 0; +} From laforge at gnumonks.org Thu May 12 06:48:45 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 May 2011 08:48:45 +0200 Subject: [PATCH]: Implement SMS decoding In-Reply-To: <1305167235.2213.8.camel@deckard> References: <1305167235.2213.8.camel@deckard> Message-ID: <20110512064845.GB10403@prithivi.gnumonks.org> Hi Gianni, On Thu, May 12, 2011 at 03:27:15AM +0100, Gianni Tedesco wrote: > Attached patch implements SMS decoding. are you aware that we already have 7bit decoding routines in libosmogsm, as well as other SMS parsing code in OpenBSC? I would prefer if we have one implementation that is in the shared library and re-used by all the various Osmocom projects. Maybe the existing routines are not suitable right-away, then they should be adapted. But two implementations for the same task doesn't sound like a good solution to me. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gianni at scaramanga.co.uk Thu May 12 06:58:40 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Thu, 12 May 2011 07:58:40 +0100 Subject: [PATCH]: Implement SMS decoding In-Reply-To: <20110512064845.GB10403@prithivi.gnumonks.org> References: <1305167235.2213.8.camel@deckard> <20110512064845.GB10403@prithivi.gnumonks.org> Message-ID: <1305183520.2213.12.camel@deckard> On Thu, 2011-05-12 at 08:48 +0200, Harald Welte wrote: > Hi Gianni, > > On Thu, May 12, 2011 at 03:27:15AM +0100, Gianni Tedesco wrote: > > > Attached patch implements SMS decoding. > > are you aware that we already have 7bit decoding routines in libosmogsm, > as well as other SMS parsing code in OpenBSC? I would prefer if we have > one implementation that is in the shared library and re-used by all the > various Osmocom projects. > > Maybe the existing routines are not suitable right-away, then they > should be adapted. But two implementations for the same task doesn't > sound like a good solution to me. No, I wasn't aware of that, I'll check it out. I am planning to progress this work by sending back the CP-ACK, adding an API so that the SMS can be "delivered" via a function pointer somwhere and provide another API to send the RP-ACK + SMS-DELIVER-REPORT. I think that should complete it? But I'm only just getting familiar with the specs. Will re-submit when I make the relevant changes. Thanks for the feedback Gianni From gianni at scaramanga.co.uk Thu May 12 09:22:57 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Thu, 12 May 2011 10:22:57 +0100 Subject: [PATCH]: Implement SMS decoding In-Reply-To: <20110512064845.GB10403@prithivi.gnumonks.org> References: <1305167235.2213.8.camel@deckard> <20110512064845.GB10403@prithivi.gnumonks.org> Message-ID: <1305192177.2213.20.camel@deckard> On Thu, 2011-05-12 at 08:48 +0200, Harald Welte wrote: > Hi Gianni, > > On Thu, May 12, 2011 at 03:27:15AM +0100, Gianni Tedesco wrote: > > > Attached patch implements SMS decoding. > > are you aware that we already have 7bit decoding routines in libosmogsm, > as well as other SMS parsing code in OpenBSC? I would prefer if we have > one implementation that is in the shared library and re-used by all the > various Osmocom projects. The 7bit decoding routines are useful as is, I'll go ahead and use them. However, the SMS decode in OpenBSC (gsm_04_11.c) is very nice but its decoding everything we want to transmit and constructing everything we want to decode! Not sure how to share that? Maybe some strings, structs and numbers, unless it was an off the cuff suggestion or I am missing something? > Maybe the existing routines are not suitable right-away, then they > should be adapted. But two implementations for the same task doesn't > sound like a good solution to me. If you can propose a way to move us there incrementally (for the CP/RP/SMS-DELIVER etc.), I'm all ears. I've only just dipped my toe in the pool here don't forget :) Gianni From ran-kun at gmx.de Thu May 12 14:04:17 2011 From: ran-kun at gmx.de (Tom Mayer) Date: Thu, 12 May 2011 16:04:17 +0200 Subject: reading bts parameters Message-ID: <4DCBE8E1.3050600@gmx.de> hello, I am not quite sure if this is the right place to ask, so sorry in advance for spamming ir i'm in the wrong place. I have build and run osmocom on my C123. I am using it for a university project and we try to read parameters from surrounding BTS. The final goal will be to separate real bts from imsi catchers. So my question is, can I use the osmocom library to gather some data from surrounding BTS? Are there some example programs? Would anyone know a good way to read the SIM data from the connected C123? Thanks in advance! Cheers Tom ---------------------------------------------------------------------------- Short example scenario: A very obvious catcher fault would be not having set the regional code or having set a wrong regional code. So it would theoretically be possible to read the regional code from the own SIM card and the regional code of the transmitting BTS and compare those. From holger at freyther.de Thu May 12 15:26:23 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 12 May 2011 17:26:23 +0200 Subject: reading bts parameters In-Reply-To: <4DCBE8E1.3050600@gmx.de> References: <4DCBE8E1.3050600@gmx.de> Message-ID: <4DCBFC1F.1060000@freyther.de> On 05/12/2011 04:04 PM, Tom Mayer wrote: > hello, > > So my question is, can I use the osmocom library to gather some data from > surrounding BTS? Are there some example programs? Would anyone know a good way > to read the SIM data from the connected C123? Hi Tom, have you looked at the source yet? From ran-kun at gmx.de Fri May 13 14:35:43 2011 From: ran-kun at gmx.de (Tom) Date: Fri, 13 May 2011 07:35:43 -0700 (PDT) Subject: reading bts parameters In-Reply-To: <4DCBFC1F.1060000@freyther.de> References: <4DCBE8E1.3050600@gmx.de> <4DCBFC1F.1060000@freyther.de> Message-ID: <1305297343767-2935310.post@n3.nabble.com> Thanks for your quick replies. I have not yet looked at the code, since somehow the mails haven't been forwarded to me. I just stumbled upon the website and read that there were answers to my post. I will look into it this weekend. At the moment there is not git repository since I am sitll in evaluation phase. It is for my masters thesis. I will definitely make the repository public once I start working on it. For now I have played around with the mobile application. "show ba 1" could yield a list with band allocations of networks (correct me there if I am wrong), I geuss this might be the stations that are around this area. "show cell 1" gives some information on the connected cell. I have seen that there is an option to put the arfcn behind the "show cell 1". does this mean you can scan a arbitrary cell of which you know the arfcn? I also put a SIM card in the c123 and tried "show subscriber 1" which yield "No SIM present". Do I have to specify the SIM in the mobile.cfg maybe? IS there any example mobile.cfg or some docs on the format? Thanks in advance for your time. Cheers Tom -- View this message in context: http://baseband-devel.722152.n3.nabble.com/reading-bts-parameters-tp2932243p2935310.html Sent from the baseband-devel mailing list archive at Nabble.com. From meierk at informatik.uni-freiburg.de Fri May 13 15:05:03 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Fri, 13 May 2011 17:05:03 +0200 Subject: reading bts parameters In-Reply-To: <1305297343767-2935310.post@n3.nabble.com> References: <4DCBE8E1.3050600@gmx.de> <4DCBFC1F.1060000@freyther.de> <1305297343767-2935310.post@n3.nabble.com> Message-ID: <4DCD489F.2010700@informatik.uni-freiburg.de> Am 13.05.2011 16:35, schrieb Tom: > Thanks for your quick replies. I have not yet looked at the code, since > somehow the mails haven't been forwarded to me. I just stumbled upon the > website and read that there were answers to my post. I will look into it > this weekend. > At the moment there is not git repository since I am sitll in evaluation > phase. It is for my masters thesis. I will definitely make the repository > public once I start working on it. > > For now I have played around with the mobile application. "show ba 1" could > yield a list with band allocations of networks (correct me there if I am > wrong), I geuss this might be the stations that are around this area. > "show cell 1" gives some information on the connected cell. I have seen that > there is an option to put the arfcn behind the "show cell 1". does this mean > you can scan a arbitrary cell of which you know the arfcn? > I also put a SIM card in the c123 and tried "show subscriber 1" which yield > "No SIM present". Do I have to specify the SIM in the mobile.cfg maybe? IS > there any example mobile.cfg or some docs on the format? > > Thanks in advance for your time. > Cheers > Tom Hi Tom, Please visit my office next week. I will answer your questions. Have a nice weekend. Regards Konrad From dario.lombardo at libero.it Thu May 12 15:43:48 2011 From: dario.lombardo at libero.it (Dario Lombardo) Date: Thu, 12 May 2011 17:43:48 +0200 Subject: reading bts parameters In-Reply-To: <4DCBE8E1.3050600@gmx.de> References: <4DCBE8E1.3050600@gmx.de> Message-ID: <4DCC0034.7070304@libero.it> On 05/12/2011 04:04 PM, Tom Mayer wrote: > So my question is, can I use the osmocom library to gather some data > from surrounding BTS? Are there some example programs? Would anyone > know a good way to read the SIM data from the connected C123? > I think that cell_log is the right osmocom app to start from. As its name said it's an application that logs data from cells... Slight changes can give you whatever you need. Dario. From holger at freyther.de Thu May 12 16:34:28 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 12 May 2011 18:34:28 +0200 Subject: reading bts parameters In-Reply-To: <4DCBE8E1.3050600@gmx.de> References: <4DCBE8E1.3050600@gmx.de> Message-ID: <4DCC0C14.4070200@freyther.de> On 05/12/2011 04:04 PM, Tom Mayer wrote: > hello, > > I am not quite sure if this is the right place to ask, so sorry in advance for > spamming ir i'm in the wrong place. Hi, one more interesting question (hardly learned from the past), will you develop the code in the open? What is the URL of your git repository? holger From laforge at gnumonks.org Thu May 12 18:09:37 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 May 2011 20:09:37 +0200 Subject: Planning for Radio Village at 2011 CCC Camp Message-ID: <20110512180936.GA25011@prithivi.gnumonks.org> Hi all! [This message is cross-posted to many lists, please be careful when replying to it! Think twice if your respones really matters to all those projects...] In order to do some better planning for our Camp activities this summer, I would like to request all people who intend to participate in the radio village to add themselves to the wiki: https://events.ccc.de/camp/2011/wiki/index.php/RadioVillage The list of citizens is auto-generated if you use Person template like I have done in my user page at https://events.ccc.de/camp/2011/wiki/index.php/User:LaForge The large main tent is not really intended as a place to sleep, but more like a place where we set up our gear and work on the various projects, similar to what happened at HAR. Thanks in advance! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From gianni at scaramanga.co.uk Fri May 13 10:21:34 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Fri, 13 May 2011 11:21:34 +0100 Subject: Anybody using a BTS for debugging? Message-ID: <1305282094.2213.42.camel@deckard> Hi, It seems like a BTS is required in order to really debug anything one develops with osmocombb. I'm still looking at implementing SMS. However the only off-the-shelf option seems to be USRP which is about $1,000 right? Is this going to become a very expensive hobby or are there cheaper options here? Is there a way to bypass L1CTL on the phone and feed the data in to, say, openBTS? If not, it would seem useful to hack such a thing up... Gianni From mhtajik at gmail.com Fri May 13 10:30:35 2011 From: mhtajik at gmail.com (Mohammad Hosein) Date: Fri, 13 May 2011 15:00:35 +0430 Subject: Anybody using a BTS for debugging? In-Reply-To: <1305282094.2213.42.camel@deckard> References: <1305282094.2213.42.camel@deckard> Message-ID: you could use most GSM test systems for such purpose . on ebay you might find very cheap ones regards On Fri, May 13, 2011 at 2:51 PM, Gianni Tedesco wrote: > Hi, > > It seems like a BTS is required in order to really debug anything one > develops with osmocombb. I'm still looking at implementing SMS. However > the only off-the-shelf option seems to be USRP which is about $1,000 > right? Is this going to become a very expensive hobby or are there > cheaper options here? > > Is there a way to bypass L1CTL on the phone and feed the data in to, > say, openBTS? If not, it would seem useful to hack such a thing up... > > Gianni > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianni at scaramanga.co.uk Fri May 13 10:41:35 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Fri, 13 May 2011 11:41:35 +0100 Subject: Anybody using a BTS for debugging? In-Reply-To: References: <1305282094.2213.42.camel@deckard> Message-ID: <1305283295.2213.45.camel@deckard> On Fri, 2011-05-13 at 15:00 +0430, Mohammad Hosein wrote: > you could use most GSM test systems for such purpose . on ebay you > might find very cheap ones > regards Any idea of model numbers? The ones I've looked at have been > $1,000 and only do calls, not SMS for example. Thanks Gianni From mhtajik at gmail.com Thu May 19 16:39:04 2011 From: mhtajik at gmail.com (Mohammad Hosein) Date: Thu, 19 May 2011 21:09:04 +0430 Subject: Anybody using a BTS for debugging? In-Reply-To: <1305822872.4405.6.camel@deckard> References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> Message-ID: most of the test systems are not built to be used for on-air operations . the ones that offer such features must be used in Shield rooms where no signal gets in or out . these rooms are expensive but usually tech universities have some rental hours for their shield and antenna rooms . its expensive as well , otherwise you are probably going to have some conflict with local regulatory sooner or later regards On Thu, May 19, 2011 at 9:04 PM, Gianni Tedesco wrote: > On Fri, 2011-05-13 at 15:00 +0430, Mohammad Hosein wrote: > > you could use most GSM test systems for such purpose . on ebay you > > might find very cheap ones > > regards > > I managed to track down a Racal 6103. It should arrive in next couple of > days. > > As a followup question then, I guess that these are intended for wired > rf connection or at least they transmit at very low power, and tell the > phone to do the same. > > However, one would feel a lot better using a channel unused by other > cells in my location. I've been using cell_log to put together a list of > active ARFCN's that my handset receives broadcasts from. Script for > parsing cell_log logs is attached. > > Am I to conclude that if cell_log hasn't dumped: > > [sysinfo] > arfcn 99 > > for example, after running for a reasonably long period of time (say > 24hrs) that operating test equipment on channel 99 should be safe? > > Gianni > > -- > > #!/usr/bin/python > > def getline(f): > while True: > l = f.readline() > if not l: > raise StopIteration > l = l.rstrip('\r\n') > if not l: > continue > yield l > def bsic(v): > (a,b) = v.split(',') > return (int(a),int(b)) > > def hexdump(v): > ret = bytearray() > for x in v.split(): > ret.append(int(x, 16)) > return ret > > class Parser: > pass > > class Power(Parser): > def line(self, s): > return > > class mcc: > tbl = {0x234: 'UK and Northern Ireland'} > def __init__(self, num): > x = ((num & 0xf00) >> 8, > (num & 0xf000) >> 12, > (num & 0xf)) > self.val = (x[0] << 8) | x[1] << 4 | x[2] > def __int__(self): > return self.val > def __str__(self): > return self.tbl.get(self.val, '%.3x'%self.val) > > class mnc: > tbl = {0x15: 'Vodafone', > 0x30: 'T-Mobile', > 0x10: 'O2', > 0x33: 'Orange', > } > def __init__(self, num): > x = ((num & 0xf0) >> 4, > (num & 0xf)) > self.val = (x[1] << 4) | x[0] > def __int__(self): > return self.val > def __str__(self): > return self.tbl.get(self.val, '%.2x'%self.val) > > class SystemInfo: > pass > > class SystemInfo3(SystemInfo): > def __init__(self, b): > if isinstance(b, str): > b = hexdump(b) > assert(b[0] > 9) # len > assert(b[1] == 0x06) # discr > assert(b[2] == 0x1b) # sysinfo3 > self.cell = (b[3] << 8) | b[4] > self.mcc = mcc((b[5] << 8) | b[6]) > self.mnc = mnc(b[7]) > self.lac = (b[8] << 8) | b[9] > def __str__(self): > return 'Cell(%s, %s)'%(self.mcc,self.mnc) > > class SystemInfo4(SystemInfo): > def __init__(self, b): > if isinstance(b, str): > b = hexdump(b) > assert(b[0] > 7) # len > assert(b[1] == 0x06) # discr > assert(b[2] == 0x1c) # sysinfo4 > self.cell = None > self.mcc = mcc((b[3] << 8) | b[4]) > self.mnc = mnc(b[5]) > self.lac = (b[6] << 8) | b[7] > def __str__(self): > return 'Cell(%s, %s)'%(self.mcc,self.mnc) > > class Sysinfo(Parser): > _keys = {'arfcn':int, > 'time':int, > 'rxlev':int, > 'bsic':bsic, > 'si1':hexdump, > 'si2':hexdump, > 'si2bis':hexdump, > 'si2ter':hexdump, > 'si3':SystemInfo3, > 'si4':SystemInfo4, > 'ta':int} > def line(self, s): > (k,v) = s.split(None, 1) > if self._keys.has_key(k): > setattr(self, k, self._keys[k](v)) > else: > print k, v > return > > class RFMap: > arfcns = {} > cells = {} > def commit(self, obj): > if isinstance(obj, Sysinfo): > self.arfcns.setdefault(obj.arfcn, {}) > self.arfcns[obj.arfcn][str(obj.si3.mnc)] = None > self.arfcns[obj.arfcn][str(obj.si4.mnc)] = None > > self.cells.setdefault(obj.si3.cell, {}) > self.cells[obj.si3.cell][str(obj.si3.mnc)] = None > elif isinstance(obj, Power): > return > assert(isinstance(obj, Parser)) > > def rf_map(f): > smap = {'[power]':Power, '[sysinfo]':Sysinfo} > obj = None > m = RFMap() > > for x in getline(f): > if x[0] == '[': > if obj is not None: > m.commit(obj) > obj = smap[x]() > continue > if obj is None: > raise ValueError, 'Bad state' > obj.line(x) > > if obj is not None: > m.commit(obj) > > print 'Active ARFCNs:' > x = m.arfcns.keys() > x.sort() > for i in x: > print ' %4d:'%i, ','.join(m.arfcns[i]) > print > > print 'Active Cells:' > x = m.cells.keys() > x.sort() > for i in x: > print ' 0x%.4x'%i, ','.join(m.cells[i]) > print > > def main(argv): > if len(argv) > 1: > infile = open(argv[1]) > else: > from sys import stdin > infile = stdin > > rf_map(infile) > return 0 > > if __name__ == '__main__': > from sys import argv > raise SystemExit, main(argv) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianni at scaramanga.co.uk Thu May 19 16:42:56 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Thu, 19 May 2011 17:42:56 +0100 Subject: Anybody using a BTS for debugging? In-Reply-To: References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> Message-ID: <1305823376.4405.8.camel@deckard> On Thu, 2011-05-19 at 21:09 +0430, Mohammad Hosein wrote: > most of the test systems are not built to be used for on-air > operations . the ones that offer such features must be used in Shield > rooms where no signal gets in or out . these rooms are expensive but > usually tech universities have some rental hours for their shield and > antenna rooms . its expensive as well , otherwise you are probably > going to have some conflict with local regulatory sooner or later > regards So how does it work "off-air"? I'll need a shielded cable and attach it on to the antenna pads of the handset? The last thing I want is regulatory hassles. Thanks Gianni From 246tnt at gmail.com Thu May 19 17:03:41 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 19 May 2011 19:03:41 +0200 Subject: Anybody using a BTS for debugging? In-Reply-To: <1305823376.4405.8.camel@deckard> References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> Message-ID: Hi, > So how does it work "off-air"? I'll need a shielded cable and attach it > on to the antenna pads of the handset? You need to use a RF 50 ohm coax cable. The Racal has a N connector and the phone should have one has well. I don't remember the exact reference of the C123 connector but I know digikey has adapter to SMA for it, so I use a N to SMA then an adaptor that depends on the phone. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianni at scaramanga.co.uk Thu May 19 17:27:59 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Thu, 19 May 2011 18:27:59 +0100 Subject: Anybody using a BTS for debugging? In-Reply-To: References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> Message-ID: <1305826079.4405.14.camel@deckard> On Thu, 2011-05-19 at 19:03 +0200, Sylvain Munaut wrote: > Hi, > > > So how does it work "off-air"? I'll need a shielded cable and attach > it > > on to the antenna pads of the handset? > > You need to use a RF 50 ohm coax cable. The Racal has a N connector > and the phone should have one has well. I don't remember the exact > reference of the C123 connector but I know digikey has adapter to SMA > for it, so I use a N to SMA then an adaptor that depends on the phone. The unit I'm getting should come with a "BNC to N-Type connector" but I thought n-type was maybe 2cm diameter? The connector on the phone (C139) is tiny, I have just uncovered it... If I understand correctly, I need a special connector for the phone and then maybe another one? eg. N to SMA depending on what the special connector provides... Looking on the list archive someone suggested: http://shop.meconet.de/artikeldet.php?suchspeicher=110448&proid=550&bez=Crimp%20male%20MS-147,%20CG-B1%20-%203.0mm,%200-6GHz,%2090%B0%20r/a But no reports as to whether it worked or not. Probably I should just get a cheap car-antenna for the phone and rip the connector out for my own cable... Thanks Gianni From squalyl at gmail.com Thu May 19 17:45:18 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Thu, 19 May 2011 19:45:18 +0200 Subject: Anybody using a BTS for debugging? In-Reply-To: <1305826079.4405.14.camel@deckard> References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> <1305826079.4405.14.camel@deckard> Message-ID: A N connector is designed for 1KW power and is half an inch in diameter :) ... It seems difficult to find the exact type of this connector even if it's present on a high number of phones. It may be a MC-Card, Hirose MS-147 is also probable: http://szwholesale.com/ebay/2/Antenna/3G-combination/antenna_connector-1.jpg You might find a short pigtail that converts this connector to SMA, then a more classical SMA-anything , maybe SMA-N or SMA-BNC followed by BNC-N. Regards Sebastien On Thu, May 19, 2011 at 7:27 PM, Gianni Tedesco wrote: > On Thu, 2011-05-19 at 19:03 +0200, Sylvain Munaut wrote: > > Hi, > > > > > So how does it work "off-air"? I'll need a shielded cable and attach > > it > > > on to the antenna pads of the handset? > > > > You need to use a RF 50 ohm coax cable. The Racal has a N connector > > and the phone should have one has well. I don't remember the exact > > reference of the C123 connector but I know digikey has adapter to SMA > > for it, so I use a N to SMA then an adaptor that depends on the phone. > > The unit I'm getting should come with a "BNC to N-Type connector" but I > thought n-type was maybe 2cm diameter? The connector on the phone (C139) > is tiny, I have just uncovered it... > > If I understand correctly, I need a special connector for the phone and > then maybe another one? eg. N to SMA depending on what the special > connector provides... > > Looking on the list archive someone suggested: > > http://shop.meconet.de/artikeldet.php?suchspeicher=110448&proid=550&bez=Crimp%20male%20MS-147,%20CG-B1%20-%203.0mm,%200-6GHz,%2090%B0%20r/a > > But no reports as to whether it worked or not. > > Probably I should just get a cheap car-antenna for the phone and rip the > connector out for my own cable... > > Thanks > > Gianni > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhtajik at gmail.com Thu May 19 17:48:06 2011 From: mhtajik at gmail.com (Mohammad Hosein) Date: Thu, 19 May 2011 22:18:06 +0430 Subject: Anybody using a BTS for debugging? In-Reply-To: <1305823376.4405.8.camel@deckard> References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> Message-ID: it really depends on the type of operation and measurement you are gonna do but you must "engineer" a way not to TX regulated traffic anyway . a shield room is your first choice , engineering the patch antenna on the handset would be another , of course you always can ask your regulatory for temporary limited license to do research and the cost depends on how crowded your area is . On Thu, May 19, 2011 at 9:12 PM, Gianni Tedesco wrote: > On Thu, 2011-05-19 at 21:09 +0430, Mohammad Hosein wrote: > > most of the test systems are not built to be used for on-air > > operations . the ones that offer such features must be used in Shield > > rooms where no signal gets in or out . these rooms are expensive but > > usually tech universities have some rental hours for their shield and > > antenna rooms . its expensive as well , otherwise you are probably > > going to have some conflict with local regulatory sooner or later > > regards > > So how does it work "off-air"? I'll need a shielded cable and attach it > on to the antenna pads of the handset? > > The last thing I want is regulatory hassles. > > Thanks > > Gianni > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu May 19 20:52:26 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 19 May 2011 22:52:26 +0200 Subject: Anybody using a BTS for debugging? In-Reply-To: References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> Message-ID: I can confirm now that it's a MS147 on the C123 I have this adapter : http://be.farnell.com/hrs-hirose/ms-147-hrmj-1/adaptor-ms147-sma/dp/1325922 and connects to the Racal using a N male -> SMA male cable. The racal is designed to be used with a direct connection, that's required to : - have precise tx / rw power measurements - ensure no signal is leaked to the outside world. Cheers, Sylvain From gianni at scaramanga.co.uk Thu May 19 21:04:00 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Thu, 19 May 2011 22:04:00 +0100 Subject: Anybody using a BTS for debugging? In-Reply-To: References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> Message-ID: <1305839040.4405.18.camel@deckard> On Thu, 2011-05-19 at 22:52 +0200, Sylvain Munaut wrote: > I can confirm now that it's a MS147 on the C123 > > I have this adapter : > > http://be.farnell.com/hrs-hirose/ms-147-hrmj-1/adaptor-ms147-sma/dp/1325922 > > and connects to the Racal using a N male -> SMA male cable. Thanks! > The racal is designed to be used with a direct connection, that's required to : > - have precise tx / rw power measurements I'm not fussed about that, just trying to work on the upper layer stuff. > - ensure no signal is leaked to the outside world. Very important > Cheers, Thanks for that! Gianni From gianni at scaramanga.co.uk Mon May 23 17:26:26 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 23 May 2011 18:26:26 +0100 Subject: Anybody using a BTS for debugging? In-Reply-To: References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> Message-ID: <1306171586.19876.0.camel@deckard> On Thu, 2011-05-19 at 22:52 +0200, Sylvain Munaut wrote: > I can confirm now that it's a MS147 on the C123 > > I have this adapter : > > http://be.farnell.com/hrs-hirose/ms-147-hrmj-1/adaptor-ms147-sma/dp/1325922 > > and connects to the Racal using a N male -> SMA male cable. Something like this? http://uk.farnell.com/huber-suhner/st-18-smam-nm-36/lead-n-plug-sma-plug-36-ins/dp/8558540?in_merch=true&MER=i-9b10-00001422 ?88 GBP seems a bit much, no?! Gianni From gianni at scaramanga.co.uk Mon May 23 18:40:30 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 23 May 2011 19:40:30 +0100 Subject: Anybody using a BTS for debugging? In-Reply-To: <1306171586.19876.0.camel@deckard> References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> <1306171586.19876.0.camel@deckard> Message-ID: <1306176030.19876.1.camel@deckard> On Mon, 2011-05-23 at 18:26 +0100, Gianni Tedesco wrote: > On Thu, 2011-05-19 at 22:52 +0200, Sylvain Munaut wrote: > > I can confirm now that it's a MS147 on the C123 > > > > I have this adapter : > > > > http://be.farnell.com/hrs-hirose/ms-147-hrmj-1/adaptor-ms147-sma/dp/1325922 > > > > and connects to the Racal using a N male -> SMA male cable. > > Something like this? > > http://uk.farnell.com/huber-suhner/st-18-smam-nm-36/lead-n-plug-sma-plug-36-ins/dp/8558540?in_merch=true&MER=i-9b10-00001422 > > ?88 GBP seems a bit much, no?! This looks like the right thing and is only ?3.80 http://www.broadbandbuyer.co.uk/Shop/ShopDetail.asp?ProductID=6195 Gianni From gianni at scaramanga.co.uk Mon May 23 20:11:06 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 23 May 2011 21:11:06 +0100 Subject: Anybody using a BTS for debugging? In-Reply-To: <1306176030.19876.1.camel@deckard> References: <1305282094.2213.42.camel@deckard> <1305822872.4405.6.camel@deckard> <1305823376.4405.8.camel@deckard> <1306171586.19876.0.camel@deckard> <1306176030.19876.1.camel@deckard> Message-ID: <1306181466.19876.24.camel@deckard> On Mon, 2011-05-23 at 19:40 +0100, Gianni Tedesco wrote: > On Mon, 2011-05-23 at 18:26 +0100, Gianni Tedesco wrote: > > On Thu, 2011-05-19 at 22:52 +0200, Sylvain Munaut wrote: > > > I can confirm now that it's a MS147 on the C123 > > > > > > I have this adapter : > > > > > > http://be.farnell.com/hrs-hirose/ms-147-hrmj-1/adaptor-ms147-sma/dp/1325922 > > > > > > and connects to the Racal using a N male -> SMA male cable. > > > > Something like this? > > > > http://uk.farnell.com/huber-suhner/st-18-smam-nm-36/lead-n-plug-sma-plug-36-ins/dp/8558540?in_merch=true&MER=i-9b10-00001422 > > > > ?88 GBP seems a bit much, no?! > > This looks like the right thing and is only ?3.80 > > http://www.broadbandbuyer.co.uk/Shop/ShopDetail.asp?ProductID=6195 OK, its been pointed out to me that this is the reverse threaded SMA connector and won't work. However, female BNC to male SMA pigtails can be found here for around ?2 from a supplier in China. http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=300554595076#ht_1743wt_907 So that means: - racal 6103 - 1m n-type -> bnc cable (supplied with unit in my case) - bnc -> sma pigtail - sma -> ms147 (or equivalent connector depending on the phone) Gianni From spaar at mirider.augusta.de Fri May 13 18:01:38 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Fri, 13 May 2011 18:01:38 CEST Subject: Anybody using a BTS for debugging? Message-ID: <4dcd7202.mirider@mirider.augusta.de> Hello Gianni, On Fri, 13 May 2011 11:41:35 +0100, "Gianni Tedesco" wrote: > > Any idea of model numbers? The ones I've looked at have been > $1,000 > and only do calls, not SMS for example. The Racal 6103E can do SMS and sometimes is available for less than $US 500 (a few cheap ones were sold in the UK a while ago). Be aware of the 6103G or the "Anite" variant, they cannot be used "standalone". Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From hwelte at sysmocom.de Fri May 13 16:39:18 2011 From: hwelte at sysmocom.de (Harald Welte) Date: Fri, 13 May 2011 18:39:18 +0200 Subject: Osmocom project vs. sysmocom GmbH Message-ID: <20110513163918.GU25011@prithivi.gnumonks.org> Hi all! As some of you already know, Holger and I have recently started a new company called "sysmocom - systems for mobile communications GmbH". The process of establishing the new company has now formally concluded. Before some rumours start to spread, we would like to clarify some points and make sure there is mutual understanding between the Osmocom community and the sysmocom company. sysmocom is intended to provide commercial offerings related to the Osmocom projects. This is not entirely new. Especially on the network side, people like Holger and I have been doing quite a lot of paid development to bring those projects forward. We would not have many of the features we have today, if it wasn't for customers who actually pay us for development of OpenBSC, OsmoBSC, OsmoSGSN and the various side projects more targetted at a real network operator like cellmgr-ng, bsc-nat, gb_proxy - just to name a few. However, this has always only been freelancing development of Software. With sysmocom, we want to go one step further and work on hardware products related to the various Free Software projects. Right now I don't want to talk too much about unfinished products, but we are working towards an inexpensive BTS product, we are funding the prototypes for Osmocom SIMtrace, and we will likely also see stuff like OpenBSC appliances. Given our past involvement and exposure into other projects that share a split Free Software / business set-up, we think we understand very well where potential issues of conflict between the two sides may be. Let me make some more clarification what this is not about: * sysmocom is not about creating proprietary derivates of Osmocom software. We work on Free Software which is publicly available under OSI approved and FSF endorsed licenses. We may offer proprietary hardware and sometimes software - but those are independent projects from existing Osmocom software. * we specifically will not have a public and a non-public version of the same program with differences in features. * sysmocom is not a VC-funded startup. It's a very small company run out of personal funds with no intention to take external funding or grow rapidly. Nobody but Holger and I determine where it goes and what it does. * sysmocom does not hold any copyright on the Free Software projects. The copyrights stay distributed with the major authors such as Holger, Onwaves, Sylvain, Dieter, Andreas and myself. None of the others have any affiliation with sysmocom. I have (personally, unrelated to sysmocom) asked some of the smaller contributors for a copyright transfer to make sure we could do the AGPLv3 transition, or future re-licensing decisions without having to ask dozens and dozens of people. sysmocom does not seek to control the Free Software projects. * we will maintain a strict separation between the community side of things and the business side. Unlike some other popular projects, we will not end up in a situation where the osmocom.org websites will be full of advertisements and hidden links that lure you on the company website. * we will keep a strict separation of naming. Osmocom is for the FOSS projects, sysmocom for the business. The company will use the term "Osmocom" only in descriptive context, not as a product name, brand or for advertisement. If you do have any concerns, please feel free to share them. However, I'd like to avoid cross-posting them throguh different mailing lists. Please follow-up-to openbsc at lists.osmocom.org Regards, Harald -- - Harald Welte http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: Digital signature URL: From suraev at stud.ntnu.no Fri May 13 17:45:36 2011 From: suraev at stud.ntnu.no (suraev at stud.ntnu.no) Date: Fri, 13 May 2011 19:45:36 +0200 Subject: L1 corruption? Message-ID: <4DCD6E40.4020400@stud.ntnu.no> Hi. I'm trying to follow the logic described in app_ccch_scan to send RACH bursts to my openbts. First 2-2 goes fine but after that I got constant errors - see below. It looks like after I've sent couple of packets something got corrupted in L1. How can I debug this and understand what causing all the errors? LOG: <0001> app_rach_send.c:227 registering signal handler... <0001> app_rach_send.c:229 resetting L1... <0001> app_rach_send.c:231 L3 init... <0001> app_rach_send.c:190 requesting FBSB from L1... <0001> app_rach_send.c:200 unhandled callback 1 fired... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:73 SI2 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:75 SI3 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:75 SI3 on the wrong TC: 0 <0001> app_rach_send.c:200 unhandled callback 5 fired... <0001> app_rach_send.c:200 unhandled callback 5 fired... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 ... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:70 SI1 received. <0001> app_rach_send.c:127 sending RACH #0 on ARFCN 21... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:127 sending RACH #1 on ARFCN 21... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:127 sending RACH #2 on ARFCN 21... <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 62 bit errors <000b> l1ctl.c:210 Dropping frame with 60 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors From hoffmaje at informatik.uni-freiburg.de Sat May 14 10:26:47 2011 From: hoffmaje at informatik.uni-freiburg.de (Jens Hoffmann) Date: Sat, 14 May 2011 12:26:47 +0200 Subject: arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) Message-ID: <4DCE58E7.1060904@informatik.uni-freiburg.de> Hi, when compiling the firmware I get the following error: make[2]: Entering directory `/home/hoffmaje/proseminar/install/osmocom-bb/src/target/firmware' LD board/mt62xx/loader_mtk.mtkram.elf arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) I used a tool-chain mentioned in a post from 18. January 2011: ftp://ftp.pengutronix.de/pub/oselas/oselas.toolchain-1.99.3.6-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18_i386.tar.bz2 I read the PreliminaryRequirements , the archives and I did a google search; I would be even glad just to understand what this error is about. Thanks for your help, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6326 bytes Desc: S/MIME Cryptographic Signature URL: From wolfram at the-dreams.de Sat May 14 19:50:47 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sat, 14 May 2011 21:50:47 +0200 Subject: arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) In-Reply-To: <4DCE58E7.1060904@informatik.uni-freiburg.de> References: <4DCE58E7.1060904@informatik.uni-freiburg.de> Message-ID: <4DCEDD17.2010305@the-dreams.de> Hi, > when compiling the firmware I get the following error: Hmm, are you compiling clean current head? Works fine here. > make[2]: Entering directory > `/home/hoffmaje/proseminar/install/osmocom-bb/src/target/firmware' Cool, what kind of proseminar? > LD board/mt62xx/loader_mtk.mtkram.elf > arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf > section .rodata) > arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf > section .rodata) > > > I used a tool-chain mentioned in a post from 18. January 2011: > > ftp://ftp.pengutronix.de/pub/oselas/oselas.toolchain-1.99.3.6-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18_i386.tar.bz2 There is also a 4.5.2 in the oselas-directory; you could try it, though I fear there is something else different on our machines. > and I did a google search; I would be even glad just to understand what > this error is about. As the error message suggests: ?OUT OF MEMORY ERROR Check the linker script for the setup. Regards, Wolfram From marco_schwan at arcor.de Sat May 14 20:54:05 2011 From: marco_schwan at arcor.de (Marco Schwan) Date: Sat, 14 May 2011 22:54:05 +0200 Subject: problem with Pirelli DP-L10 and upload the firmware Message-ID: <4DCEEBED.8070707@arcor.de> Hi, I have a problem with the DP-L10. The upload the firmware in the phone is not succesfull. I have made following steps: - change the UART number in the two header files - compile the source - connected the phone with laptop - run the command "./host/osmocon/osmocon -p /dev/ttyUSB0 -m romload ./target/firmware/board/pirelli_dpl10/layer1.highram.bin" - put the accu in the mobile phone the upload the firmware start and the last message from osmocon is: handle_write_block(): 64 bytes (1024/1024) handle_write_block(): Block 51 finished Finished, sent 51 blocks in total Received block ack from phone Sending checksum: 0x55 I have follow message expected: Received block ack from phone Sending checksum: 0xaa Checksum on phone side matches, let's branch to your code Branching to 0x00820000 Received branch ack, your code is running now! I see not the error. Can you please a idea give. Marco From pablo at gnumonks.org Sun May 15 13:04:15 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 15 May 2011 15:04:15 +0200 Subject: linking error on board mt62xx (current git tree) Message-ID: <4DCFCF4F.1090809@gnumonks.org> Hi Wolfram, I hit the following linking error in the current LD board/mt62xx/loader_mtk.mtkram.elf arm-elf-ld: address 0x400050ec of board/mt62xx/loader_mtk.mtkram.elf section .text is not within region LRAM make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Error 1 I'm not familiar with those bits, any clue on what's wrong? Thanks. From wolfram at the-dreams.de Sun May 15 17:58:58 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Sun, 15 May 2011 19:58:58 +0200 Subject: linking error on board mt62xx (current git tree) In-Reply-To: <4DCFCF4F.1090809@gnumonks.org> References: <4DCFCF4F.1090809@gnumonks.org> Message-ID: <4DD01462.10503@the-dreams.de> > I hit the following linking error in the current > > LD board/mt62xx/loader_mtk.mtkram.elf > arm-elf-ld: address 0x400050ec of board/mt62xx/loader_mtk.mtkram.elf > section .text is not within region LRAM > make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Error 1 > > I'm not familiar with those bits, any clue on what's wrong? Thanks. What toolchain? From klaus.rechert at rz.uni-freiburg.de Mon May 16 20:09:48 2011 From: klaus.rechert at rz.uni-freiburg.de (Klaus Rechert) Date: Mon, 16 May 2011 22:09:48 +0200 Subject: linking error on board mt62xx (current git tree) In-Reply-To: <4DD01462.10503@the-dreams.de> References: <4DCFCF4F.1090809@gnumonks.org> <4DD01462.10503@the-dreams.de> Message-ID: <4DD1848C.8050900@rz.uni-freiburg.de> >> I hit the following linking error in the current >> >> LD board/mt62xx/loader_mtk.mtkram.elf >> arm-elf-ld: address 0x400050ec of board/mt62xx/loader_mtk.mtkram.elf >> section .text is not within region LRAM >> make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Error 1 >> >> I'm not familiar with those bits, any clue on what's wrong? Thanks. > > What toolchain? > Same here: arm-elf-ld: address 0x400053dc of board/mt62xx/loader_mtk.mtkram.elf section .text is not within region LRAM make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Error 1 make: *** [mtk-firmware] Error 2 arm-elf-ld -version GNU ld version 2.14 20030612 which comes with the GNUARM MacOSX prebuilt toolchain (GCC 3.3). Cheers Klaus From zero-kelvin at gmx.de Tue May 17 04:49:47 2011 From: zero-kelvin at gmx.de (dexter) Date: Tue, 17 May 2011 06:49:47 +0200 Subject: linking error on board mt62xx (current git tree) In-Reply-To: <4DD1848C.8050900@rz.uni-freiburg.de> References: <4DCFCF4F.1090809@gnumonks.org> <4DD01462.10503@the-dreams.de> <4DD1848C.8050900@rz.uni-freiburg.de> Message-ID: <4DD1FE6B.9010006@gmx.de> Hi folks > > Same here: > arm-elf-ld: address 0x400053dc of board/mt62xx/loader_mtk.mtkram.elf > section .text is not within region LRAM > make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Error 1 > make: *** [mtk-firmware] Error 2 I see I am not alone ;-) I did not need the mt62xx stuff so i commented this out in makefile.mtk #BOARDS?=mt62xx .... i must go now - it is time for uni. regards. Philipp From peter at stuge.se Thu May 19 15:45:34 2011 From: peter at stuge.se (Peter Stuge) Date: Thu, 19 May 2011 17:45:34 +0200 Subject: linking error on board mt62xx (current git tree) In-Reply-To: <4DD1848C.8050900@rz.uni-freiburg.de> References: <4DCFCF4F.1090809@gnumonks.org> <4DD01462.10503@the-dreams.de> <4DD1848C.8050900@rz.uni-freiburg.de> Message-ID: <20110519154534.23372.qmail@stuge.se> Klaus Rechert wrote: > arm-elf-ld -version > GNU ld version 2.14 20030612 > > which comes with the GNUARM MacOSX prebuilt toolchain (GCC 3.3). Try a 4.5 or 4.6 arm-none-eabi. //Peter From klaus.rechert at rz.uni-freiburg.de Thu May 19 16:01:17 2011 From: klaus.rechert at rz.uni-freiburg.de (Klaus Rechert) Date: Thu, 19 May 2011 18:01:17 +0200 Subject: linking error on board mt62xx (current git tree) In-Reply-To: <20110519154534.23372.qmail@stuge.se> References: <4DCFCF4F.1090809@gnumonks.org> <4DD01462.10503@the-dreams.de> <4DD1848C.8050900@rz.uni-freiburg.de> <20110519154534.23372.qmail@stuge.se> Message-ID: <4DD53ECD.9000605@rz.uni-freiburg.de> >> arm-elf-ld -version >> GNU ld version 2.14 20030612 >> >> which comes with the GNUARM MacOSX prebuilt toolchain (GCC 3.3). > Try a 4.5 or 4.6 arm-none-eabi. > Actually I don't need the MTK code, as I'm using the C123 (as most other users I assume). Maybe the MTK target should be not be built by default...? Cheers Klaus From meierk at informatik.uni-freiburg.de Mon May 16 20:59:36 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Mon, 16 May 2011 22:59:36 +0200 Subject: linking error on board mt62xx (current git tree) In-Reply-To: <4DD01462.10503@the-dreams.de> References: <4DCFCF4F.1090809@gnumonks.org> <4DD01462.10503@the-dreams.de> Message-ID: <4DD19038.7050603@informatik.uni-freiburg.de> Am 15.05.2011 19:58, schrieb Wolfram Sang: > >> I hit the following linking error in the current >> >> LD board/mt62xx/loader_mtk.mtkram.elf >> arm-elf-ld: address 0x400050ec of board/mt62xx/loader_mtk.mtkram.elf >> section .text is not within region LRAM >> make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Error 1 >> >> I'm not familiar with those bits, any clue on what's wrong? Thanks. > > What toolchain? Same here too: arm-elf-ld: address 0x400050ec of board/mt62xx/loader_mtk.mtkram.elf section .text is not within region LRAM make[1]: *** [board/mt62xx/loader_mtk.mtkram.elf] Fehler 1 make[1]: Verlasse Verzeichnis '/home/konrad/software/osmocom-bb/src/target/firmware' make: *** [mtk-firmware] Fehler 2 System is Ubuntu 10.04.2 with the GNUArm toolchain linked on the osmocom website. (GCC version 3.4.3 and ld version 2.15) Regards Konrad From wolfram at the-dreams.de Mon May 16 21:18:42 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 16 May 2011 23:18:42 +0200 Subject: linking error on board mt62xx (current git tree) In-Reply-To: <4DD19038.7050603@informatik.uni-freiburg.de> References: <4DCFCF4F.1090809@gnumonks.org> <4DD01462.10503@the-dreams.de> <4DD19038.7050603@informatik.uni-freiburg.de> Message-ID: <4DD194B2.9060006@the-dreams.de> > System is Ubuntu 10.04.2 with the GNUArm toolchain linked on the osmocom > website. (GCC version 3.4.3 and ld version 2.15) Okay, there seem to be still quite some old v3.x toolchains around. Truth is, the code in the steve's old branch already did not work with v3.x. Including mtk-firmware into 'make all' gave a bigger test coverage, so people seem to notice now. A quick solution would be to simply increase the sections in the linker script, but it might be worthwhile to check why the v3.x is so much different. I will try to address it somewhen this week, but if somebody is willing to assist, this is greatly appreciated. Newer toolchains can be found here: ftp://ftp.pengutronix.de/pub/oselas/ Regards, Wolfram From pablo at gnumonks.org Sun May 15 13:14:20 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sun, 15 May 2011 15:14:20 +0200 Subject: [PATCH 0/6] osmocom-bb: get in sync with libosmocore namespace changes Message-ID: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patchset gets osmocom-bb in sync with the namespace fixes for libosmocore. You can find them in pablo/namespace branch. Please, merge it. BTW: I had to temporarily disable mtk62xx compilation since I hit a linking error. This problem occurs in the current git tree. I already contacted Wolfram to let him know. diff --git a/src/Makefile b/src/Makefile index d6f556f..6ff4dc4 100644 --- a/src/Makefile +++ b/src/Makefile @@ -17,7 +17,7 @@ OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host LIBOSMOVTY_CFLAGS=-I$(TOPDIR)/shared/libosmocore/include \ LIBOSMOGSM_CFLAGS=-I$(TOPDIR)/shared/libosmocore/include -all: libosmocore-target nofirmware firmware mtk-firmware +all: libosmocore-target nofirmware firmware nofirmware: libosmocore-host layer23 osmocon gsmmap libosmocore-host: shared/libosmocore/build-host/src/.libs/libosmocore.la Pablo Neira Ayuso (6): src: use namespace prefix osmo_timer* src: use namespace prefix osmo_fd* and osmo_select* src: use namespace prefix osmo_signal* src: use namespace prefix osmo_wqueue* src: use namespace prefix osmo_* for utils src: use namespace prefix osmo_* for crc16 functions From pablo at gnumonks.org Sun May 15 13:14:21 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sun, 15 May 2011 15:14:21 +0200 Subject: [PATCH 1/6] src: use namespace prefix osmo_timer* In-Reply-To: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> Message-ID: <1305465266-18081-2-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Summary of changes: s/struct timer_list/struct osmo_timer_list/g s/bsc_add_timer/osmo_timer_add/g s/bsc_schedule_timer/osmo_timer_schedule/g s/bsc_del_timer/osmo_timer_del/g s/bsc_timer_pending/osmo_timer_pending/g s/bsc_nearest_timer/osmo_timers_nearest/g s/bsc_prepare_timers/osmo_timers_prepare/g s/bsc_update_timers/osmo_timers_update/g s/bsc_timer_check/osmo_timers_check/g --- src/host/layer23/include/osmocom/bb/common/lapdm.h | 2 +- .../layer23/include/osmocom/bb/mobile/gsm322.h | 4 +- .../layer23/include/osmocom/bb/mobile/gsm48_mm.h | 4 +- .../layer23/include/osmocom/bb/mobile/gsm48_rr.h | 16 +++--- src/host/layer23/include/osmocom/bb/mobile/mncc.h | 2 +- .../include/osmocom/bb/mobile/transaction.h | 4 +- src/host/layer23/src/common/lapdm.c | 42 ++++++++-------- src/host/layer23/src/misc/app_echo_test.c | 6 +- src/host/layer23/src/misc/bcch_scan.c | 4 +- src/host/layer23/src/misc/cell_log.c | 8 ++-- src/host/layer23/src/mobile/gsm322.c | 12 ++-- src/host/layer23/src/mobile/gsm48_cc.c | 6 +- src/host/layer23/src/mobile/gsm48_mm.c | 48 +++++++++--------- src/host/layer23/src/mobile/gsm48_rr.c | 50 ++++++++++---------- src/host/layer23/src/mobile/mnccms.c | 6 +- src/host/osmocon/osmocon.c | 18 ++++---- src/host/osmocon/osmoload.c | 8 ++-- src/target/firmware/comm/timer.c | 16 +++--- src/target/firmware/include/comm/timer.h | 12 ++-- 19 files changed, 134 insertions(+), 134 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/lapdm.h b/src/host/layer23/include/osmocom/bb/common/lapdm.h index 2d0e2fd..b502ffd 100644 --- a/src/host/layer23/include/osmocom/bb/common/lapdm.h +++ b/src/host/layer23/include/osmocom/bb/common/lapdm.h @@ -42,7 +42,7 @@ struct lapdm_datalink { uint32_t state; int seq_err_cond; /* condition of sequence error */ uint8_t own_busy, peer_busy; - struct timer_list t200; + struct osmo_timer_list t200; uint8_t retrans_ctr; struct llist_head send_queue; /* frames from L3 */ struct msgb *send_buffer; /* current frame transmitting */ diff --git a/src/host/layer23/include/osmocom/bb/mobile/gsm322.h b/src/host/layer23/include/osmocom/bb/mobile/gsm322.h index 467ff39..c93e8fa 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/gsm322.h +++ b/src/host/layer23/include/osmocom/bb/mobile/gsm322.h @@ -119,7 +119,7 @@ struct gsm322_plmn { struct llist_head sorted_plmn; /* list of sorted PLMN */ struct llist_head forbidden_la; /* forbidden LAs */ - struct timer_list timer; + struct osmo_timer_list timer; int plmn_curr; /* current index in sorted_plmn */ uint16_t mcc, mnc; /* current network selected */ @@ -140,7 +140,7 @@ struct gsm322_cellsel { struct llist_head event_queue; /* event messages */ struct llist_head ba_list; /* BCCH Allocation per PLMN */ - struct timer_list timer; + struct osmo_timer_list timer; uint16_t mcc, mnc; /* current network to search for */ struct gsm322_cs_list list[1024]; /* cell selection list per freq. */ diff --git a/src/host/layer23/include/osmocom/bb/mobile/gsm48_mm.h b/src/host/layer23/include/osmocom/bb/mobile/gsm48_mm.h index 447dc95..021b78d 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/gsm48_mm.h +++ b/src/host/layer23/include/osmocom/bb/mobile/gsm48_mm.h @@ -163,8 +163,8 @@ struct gsm48_mmlayer { struct llist_head event_queue; /* timers */ - struct timer_list t3210, t3211, t3212, t3213; - struct timer_list t3220, t3230, t3240; + struct osmo_timer_list t3210, t3211, t3212, t3213; + struct osmo_timer_list t3220, t3230, t3240; int t3212_value; int start_t3211; /* remember to start timer */ diff --git a/src/host/layer23/include/osmocom/bb/mobile/gsm48_rr.h b/src/host/layer23/include/osmocom/bb/mobile/gsm48_rr.h index b140c18..cccf279 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/gsm48_rr.h +++ b/src/host/layer23/include/osmocom/bb/mobile/gsm48_rr.h @@ -118,15 +118,15 @@ struct gsm48_rrlayer { struct llist_head downqueue; /* timers */ - struct timer_list t_starting; /* starting time for chan. access */ - struct timer_list t_rel_wait; /* wait for L2 to transmit UA */ - struct timer_list t3110; - struct timer_list t3122; - struct timer_list t3124; - struct timer_list t3126; + struct osmo_timer_list t_starting; /* starting time for chan. access */ + struct osmo_timer_list t_rel_wait; /* wait for L2 to transmit UA */ + struct osmo_timer_list t3110; + struct osmo_timer_list t3122; + struct osmo_timer_list t3124; + struct osmo_timer_list t3126; int t3126_value; #ifndef TODO - struct timer_list temp_rach_ti; /* temporary timer */ + struct osmo_timer_list temp_rach_ti; /* temporary timer */ #endif /* states if RR-EST-REQ was used */ @@ -169,7 +169,7 @@ struct gsm48_rrlayer { uint32_t ba_range[16]; /* measurements */ - struct timer_list t_meas; + struct osmo_timer_list t_meas; struct gsm48_rr_meas meas; uint8_t monitor; }; diff --git a/src/host/layer23/include/osmocom/bb/mobile/mncc.h b/src/host/layer23/include/osmocom/bb/mobile/mncc.h index e378ecc..a2b48cf 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/mncc.h +++ b/src/host/layer23/include/osmocom/bb/mobile/mncc.h @@ -40,7 +40,7 @@ struct gsm_call { uint8_t hold; /* call on hold */ uint8_t ring; /* call ringing/knocking */ - struct timer_list dtmf_timer; + struct osmo_timer_list dtmf_timer; uint8_t dtmf_state; uint8_t dtmf_index; char dtmf[32]; /* dtmf sequence */ diff --git a/src/host/layer23/include/osmocom/bb/mobile/transaction.h b/src/host/layer23/include/osmocom/bb/mobile/transaction.h index 6cbc25b..aa62f46 100644 --- a/src/host/layer23/include/osmocom/bb/mobile/transaction.h +++ b/src/host/layer23/include/osmocom/bb/mobile/transaction.h @@ -35,7 +35,7 @@ struct gsm_trans { /* current timer and message queue */ int Tcurrent; /* current CC timer */ int T308_second; /* used to send release again */ - struct timer_list timer; + struct osmo_timer_list timer; struct gsm_mncc msg; /* stores setup/disconnect/release message */ } cc; #if 0 @@ -43,7 +43,7 @@ struct gsm_trans { uint8_t link_id; /* RSL Link ID to be used for this trans */ int is_mt; /* is this a MO (0) or MT (1) transfer */ enum gsm411_cp_state cp_state; - struct timer_list cp_timer; + struct osmo_timer_list cp_timer; enum gsm411_rp_state rp_state; diff --git a/src/host/layer23/src/common/lapdm.c b/src/host/layer23/src/common/lapdm.c index 61e2287..974c34c 100644 --- a/src/host/layer23/src/common/lapdm.c +++ b/src/host/layer23/src/common/lapdm.c @@ -538,7 +538,7 @@ static void lapdm_t200_cb(void *data) /* increment re-transmission counter */ dl->retrans_ctr++; /* restart T200 (PH-READY-TO-SEND) */ - bsc_schedule_timer(&dl->t200, T200); + osmo_timer_schedule(&dl->t200, T200); break; case LAPDm_STATE_DISC_SENT: /* 5.4.4.3 */ @@ -562,7 +562,7 @@ static void lapdm_t200_cb(void *data) /* increment re-transmission counter */ dl->retrans_ctr++; /* restart T200 (PH-READY-TO-SEND) */ - bsc_schedule_timer(&dl->t200, T200); + osmo_timer_schedule(&dl->t200, T200); break; case LAPDm_STATE_MF_EST: /* 5.5.7 */ @@ -608,7 +608,7 @@ static void lapdm_t200_cb(void *data) } } /* restart T200 (PH-READY-TO-SEND) */ - bsc_schedule_timer(&dl->t200, T200); + osmo_timer_schedule(&dl->t200, T200); } else { /* send MDL ERROR INIDCATION to L3 */ rsl_rll_error(RLL_CAUSE_T200_EXPIRED, &dl->mctx); @@ -652,7 +652,7 @@ static void lapdm_acknowledge(struct lapdm_msg_ctx *mctx) || (rej && nr == dl->V_ack)) { LOGP(DLAPDM, LOGL_INFO, "reset t200\n"); t200_reset = 1; - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* 5.5.3.1 Note 1 + 2 imply timer recovery cond. */ } /* 5.7.4: N(R) sequence error @@ -674,7 +674,7 @@ static void lapdm_acknowledge(struct lapdm_msg_ctx *mctx) if (dl->tx_length[dl->V_send - 1]) { LOGP(DLAPDM, LOGL_INFO, "start T200, due to unacked I " "frame(s)\n"); - bsc_schedule_timer(&dl->t200, T200); + osmo_timer_schedule(&dl->t200, T200); } } } @@ -748,7 +748,7 @@ static int lapdm_rx_u(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* 5.4.6.2 send DM with F=P */ lapdm_send_dm(mctx); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); msgb_free(msg); return send_rll_simple(RSL_MT_REL_CONF, mctx); default: @@ -821,7 +821,7 @@ static int lapdm_rx_u(struct msgb *msg, struct lapdm_msg_ctx *mctx) break; case LAPDm_STATE_DISC_SENT: /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* go to idle state */ lapdm_dl_newstate(dl, LAPDm_STATE_IDLE); rc = send_rll_simple(RSL_MT_REL_CONF, mctx); @@ -836,7 +836,7 @@ static int lapdm_rx_u(struct msgb *msg, struct lapdm_msg_ctx *mctx) return 0; } /* reset T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); rc = send_rll_simple(RSL_MT_REL_IND, mctx); msgb_free(msg); break; @@ -933,7 +933,7 @@ static int lapdm_rx_u(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* 5.4.6.2 send DM with F=P */ lapdm_send_dm(mctx); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); return send_rll_simple(RSL_MT_REL_IND, mctx); case LAPDm_STATE_MF_EST: case LAPDm_STATE_TIMER_RECOV: @@ -950,7 +950,7 @@ static int lapdm_rx_u(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* send UA response */ lapdm_send_ua(mctx, length, msg->l2h + 3); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* enter idle state */ lapdm_dl_newstate(dl, LAPDm_STATE_IDLE); /* send notification to L3 */ @@ -999,7 +999,7 @@ static int lapdm_rx_u(struct msgb *msg, struct lapdm_msg_ctx *mctx) case LAPDm_STATE_DISC_SENT: LOGP(DLAPDM, LOGL_INFO, "UA in disconnect state\n"); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* go to idle state */ lapdm_dl_newstate(dl, LAPDm_STATE_IDLE); rc = send_rll_simple(RSL_MT_REL_CONF, mctx); @@ -1015,7 +1015,7 @@ static int lapdm_rx_u(struct msgb *msg, struct lapdm_msg_ctx *mctx) } LOGP(DLAPDM, LOGL_INFO, "UA in SABM state\n"); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* compare UA with SABME if contention resolution is applied */ if (dl->tx_hist[0][2] >> 2) { rc = check_length_ind(mctx, msg->l2h[2]); @@ -1135,7 +1135,7 @@ static int lapdm_rx_s(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* V(S) to the N(R) in the RR frame */ dl->V_send = LAPDm_CTRL_Nr(mctx->ctrl); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* 5.5.7 Clear timer recovery condition */ lapdm_dl_newstate(dl, LAPDm_STATE_MF_EST); } @@ -1198,7 +1198,7 @@ static int lapdm_rx_s(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* V(S) and V(A) to the N(R) in the REJ frame */ dl->V_send = dl->V_ack = LAPDm_CTRL_Nr(mctx->ctrl); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* 5.5.3.2 */ if (LAPDm_ADDR_CR(mctx->addr) == CR_BS2MS_CMD && LAPDm_CTRL_PF_BIT(mctx->ctrl)) { @@ -1246,7 +1246,7 @@ static int lapdm_rx_s(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* V(S) and V(A) to the N(R) in the REJ frame */ dl->V_send = dl->V_ack = LAPDm_CTRL_Nr(mctx->ctrl); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); } else { /* Clear an existing peer receiver busy condition */ dl->peer_busy = 0; @@ -1660,7 +1660,7 @@ static int rslms_rx_rll_est_req(struct msgb *msg, struct lapdm_datalink *dl) lapdm_dl_newstate(dl, LAPDm_STATE_SABM_SENT); /* Tramsmit and start T200 */ - bsc_schedule_timer(&dl->t200, T200); + osmo_timer_schedule(&dl->t200, T200); return tx_ph_data_enqueue(dl, msg, chan_nr, link_id, n201); } @@ -1853,8 +1853,8 @@ static int rslms_send_i(struct lapdm_msg_ctx *mctx, int line) /* If timer T200 is not running at the time right before transmitting a * frame, when the PH-READY-TO-SEND primitive is received from the * physical layer., it shall be set. */ - if (!bsc_timer_pending(&dl->t200)) - bsc_schedule_timer(&dl->t200, T200); + if (!osmo_timer_pending(&dl->t200)) + osmo_timer_schedule(&dl->t200, T200); tx_ph_data_enqueue(dl, msg, chan_nr, link_id, mctx->n201); @@ -1957,7 +1957,7 @@ static int rslms_rx_rll_res_req(struct msgb *msg, struct lapdm_datalink *dl) lapdm_dl_newstate(dl, LAPDm_STATE_SABM_SENT); /* Tramsmit and start T200 */ - bsc_schedule_timer(&dl->t200, T200); + osmo_timer_schedule(&dl->t200, T200); return tx_ph_data_enqueue(dl, msg, chan_nr, link_id, n201); } @@ -1979,7 +1979,7 @@ static int rslms_rx_rll_rel_req(struct msgb *msg, struct lapdm_datalink *dl) LOGP(DLAPDM, LOGL_INFO, "perform local release\n"); msgb_free(msg); /* reset Timer T200 */ - bsc_del_timer(&dl->t200); + osmo_timer_del(&dl->t200); /* enter idle state */ lapdm_dl_newstate(dl, LAPDm_STATE_IDLE); /* flush buffers */ @@ -2013,7 +2013,7 @@ static int rslms_rx_rll_rel_req(struct msgb *msg, struct lapdm_datalink *dl) lapdm_dl_newstate(dl, LAPDm_STATE_DISC_SENT); /* Tramsmit and start T200 */ - bsc_schedule_timer(&dl->t200, T200); + osmo_timer_schedule(&dl->t200, T200); return tx_ph_data_enqueue(dl, msg, chan_nr, link_id, dl->mctx.n201); } diff --git a/src/host/layer23/src/misc/app_echo_test.c b/src/host/layer23/src/misc/app_echo_test.c index 0adab7f..3d937d2 100644 --- a/src/host/layer23/src/misc/app_echo_test.c +++ b/src/host/layer23/src/misc/app_echo_test.c @@ -34,7 +34,7 @@ static struct { - struct timer_list timer; + struct osmo_timer_list timer; } test_data; static void test_tmr_cb(void *data) @@ -42,7 +42,7 @@ static void test_tmr_cb(void *data) struct osmocom_ms *ms = data; l1ctl_tx_echo_req(ms, 62); - bsc_schedule_timer(&test_data.timer, 1, 0); + osmo_timer_schedule(&test_data.timer, 1, 0); } int l23_app_init(struct osmocom_ms *ms) @@ -50,7 +50,7 @@ int l23_app_init(struct osmocom_ms *ms) test_data.timer.cb = &test_tmr_cb; test_data.timer.data = ms; - bsc_schedule_timer(&test_data.timer, 1, 0); + osmo_timer_schedule(&test_data.timer, 1, 0); return 0; } diff --git a/src/host/layer23/src/misc/bcch_scan.c b/src/host/layer23/src/misc/bcch_scan.c index 351da52..fc88254 100644 --- a/src/host/layer23/src/misc/bcch_scan.c +++ b/src/host/layer23/src/misc/bcch_scan.c @@ -105,7 +105,7 @@ struct full_power_scan { struct llist_head cell_list; struct cell_info *cur_cell; uint16_t cur_arfcn; - struct timer_list timer; + struct osmo_timer_list timer; }; static struct full_power_scan fps; @@ -164,7 +164,7 @@ static int _cinfo_start_arfcn(unsigned int band_arfcn) fps.cur_cell->band_arfcn = band_arfcn; /* FIXME: start timer in case we never get a sync */ fps.state = BSCAN_S_WAIT_DATA; - bsc_schedule_timer(&fps.timer, 2, 0); + osmo_timer_schedule(&fps.timer, 2, 0); return 0; } diff --git a/src/host/layer23/src/misc/cell_log.c b/src/host/layer23/src/misc/cell_log.c index 7980082..a1a764b 100644 --- a/src/host/layer23/src/misc/cell_log.c +++ b/src/host/layer23/src/misc/cell_log.c @@ -71,7 +71,7 @@ static uint16_t band_range[][2] = {{0, 124}, {512, 885}, {955, 1023}, {0, 0}}; #define INFO_FLG_SI4 128 static struct osmocom_ms *ms; -static struct timer_list timer; +static struct osmo_timer_list timer; static struct pm_info { uint16_t flags; @@ -233,8 +233,8 @@ static void timeout_cb(void *arg) static void stop_timer(void) { - if (bsc_timer_pending(&timer)) - bsc_del_timer(&timer); + if (osmo_timer_pending(&timer)) + osmo_timer_del(&timer); } static void start_timer(int sec, int micro) @@ -242,7 +242,7 @@ static void start_timer(int sec, int micro) stop_timer(); timer.cb = timeout_cb; timer.data = ms; - bsc_schedule_timer(&timer, sec, micro); + osmo_timer_schedule(&timer, sec, micro); } static void start_rach(void) diff --git a/src/host/layer23/src/mobile/gsm322.c b/src/host/layer23/src/mobile/gsm322.c index c05469d..2bd4f9c 100644 --- a/src/host/layer23/src/mobile/gsm322.c +++ b/src/host/layer23/src/mobile/gsm322.c @@ -426,15 +426,15 @@ static void start_plmn_timer(struct gsm322_plmn *plmn, int secs) secs / 60); plmn->timer.cb = plmn_timer_timeout; plmn->timer.data = plmn; - bsc_schedule_timer(&plmn->timer, secs, 0); + osmo_timer_schedule(&plmn->timer, secs, 0); } /* stop plmn search timer */ static void stop_plmn_timer(struct gsm322_plmn *plmn) { - if (bsc_timer_pending(&plmn->timer)) { + if (osmo_timer_pending(&plmn->timer)) { LOGP(DPLMN, LOGL_INFO, "Stopping pending timer.\n"); - bsc_del_timer(&plmn->timer); + osmo_timer_del(&plmn->timer); } } @@ -444,15 +444,15 @@ void start_cs_timer(struct gsm322_cellsel *cs, int sec, int micro) LOGP(DCS, LOGL_DEBUG, "Starting CS timer with %d seconds.\n", sec); cs->timer.cb = gsm322_cs_timeout; cs->timer.data = cs; - bsc_schedule_timer(&cs->timer, sec, micro); + osmo_timer_schedule(&cs->timer, sec, micro); } /* stop cell selection timer */ static void stop_cs_timer(struct gsm322_cellsel *cs) { - if (bsc_timer_pending(&cs->timer)) { + if (osmo_timer_pending(&cs->timer)) { LOGP(DCS, LOGL_DEBUG, "stopping pending CS timer.\n"); - bsc_del_timer(&cs->timer); + osmo_timer_del(&cs->timer); } } diff --git a/src/host/layer23/src/mobile/gsm48_cc.c b/src/host/layer23/src/mobile/gsm48_cc.c index b881205..5abf3f8 100644 --- a/src/host/layer23/src/mobile/gsm48_cc.c +++ b/src/host/layer23/src/mobile/gsm48_cc.c @@ -338,17 +338,17 @@ static void gsm48_start_cc_timer(struct gsm_trans *trans, int current, sec); trans->cc.timer.cb = gsm48_cc_timeout; trans->cc.timer.data = trans; - bsc_schedule_timer(&trans->cc.timer, sec, micro); + osmo_timer_schedule(&trans->cc.timer, sec, micro); trans->cc.Tcurrent = current; } /* stop various timers */ static void gsm48_stop_cc_timer(struct gsm_trans *trans) { - if (bsc_timer_pending(&trans->cc.timer)) { + if (osmo_timer_pending(&trans->cc.timer)) { LOGP(DCC, LOGL_INFO, "stopping pending timer T%x\n", trans->cc.Tcurrent); - bsc_del_timer(&trans->cc.timer); + osmo_timer_del(&trans->cc.timer); trans->cc.Tcurrent = 0; } } diff --git a/src/host/layer23/src/mobile/gsm48_mm.c b/src/host/layer23/src/mobile/gsm48_mm.c index bf5bbc2..140750a 100644 --- a/src/host/layer23/src/mobile/gsm48_mm.c +++ b/src/host/layer23/src/mobile/gsm48_mm.c @@ -382,7 +382,7 @@ static void start_mm_t3210(struct gsm48_mmlayer *mm) "seconds\n", GSM_T3210_MS); mm->t3210.cb = timeout_mm_t3210; mm->t3210.data = mm; - bsc_schedule_timer(&mm->t3210, GSM_T3210_MS); + osmo_timer_schedule(&mm->t3210, GSM_T3210_MS); } static void start_mm_t3211(struct gsm48_mmlayer *mm) @@ -391,7 +391,7 @@ static void start_mm_t3211(struct gsm48_mmlayer *mm) "%d.%d seconds\n", GSM_T3211_MS); mm->t3211.cb = timeout_mm_t3211; mm->t3211.data = mm; - bsc_schedule_timer(&mm->t3211, GSM_T3211_MS); + osmo_timer_schedule(&mm->t3211, GSM_T3211_MS); } static void start_mm_t3212(struct gsm48_mmlayer *mm, int sec) @@ -404,7 +404,7 @@ static void start_mm_t3212(struct gsm48_mmlayer *mm, int sec) "%d seconds\n", sec); mm->t3212.cb = timeout_mm_t3212; mm->t3212.data = mm; - bsc_schedule_timer(&mm->t3212, sec, 0); + osmo_timer_schedule(&mm->t3212, sec, 0); } static void start_mm_t3213(struct gsm48_mmlayer *mm) @@ -413,7 +413,7 @@ static void start_mm_t3213(struct gsm48_mmlayer *mm) "%d.%d seconds\n", GSM_T3213_MS); mm->t3213.cb = timeout_mm_t3213; mm->t3213.data = mm; - bsc_schedule_timer(&mm->t3213, GSM_T3213_MS); + osmo_timer_schedule(&mm->t3213, GSM_T3213_MS); } static void start_mm_t3220(struct gsm48_mmlayer *mm) @@ -422,7 +422,7 @@ static void start_mm_t3220(struct gsm48_mmlayer *mm) "%d.%d seconds\n", GSM_T3220_MS); mm->t3220.cb = timeout_mm_t3220; mm->t3220.data = mm; - bsc_schedule_timer(&mm->t3220, GSM_T3220_MS); + osmo_timer_schedule(&mm->t3220, GSM_T3220_MS); } static void start_mm_t3230(struct gsm48_mmlayer *mm) @@ -431,7 +431,7 @@ static void start_mm_t3230(struct gsm48_mmlayer *mm) "%d.%d seconds\n", GSM_T3230_MS); mm->t3230.cb = timeout_mm_t3230; mm->t3230.data = mm; - bsc_schedule_timer(&mm->t3230, GSM_T3230_MS); + osmo_timer_schedule(&mm->t3230, GSM_T3230_MS); } static void start_mm_t3240(struct gsm48_mmlayer *mm) @@ -440,69 +440,69 @@ static void start_mm_t3240(struct gsm48_mmlayer *mm) "seconds\n", GSM_T3240_MS); mm->t3240.cb = timeout_mm_t3240; mm->t3240.data = mm; - bsc_schedule_timer(&mm->t3240, GSM_T3240_MS); + osmo_timer_schedule(&mm->t3240, GSM_T3240_MS); } static void stop_mm_t3210(struct gsm48_mmlayer *mm) { - if (bsc_timer_pending(&mm->t3210)) { + if (osmo_timer_pending(&mm->t3210)) { LOGP(DMM, LOGL_INFO, "stopping pending (loc. upd. timeout) " "timer T3210\n"); - bsc_del_timer(&mm->t3210); + osmo_timer_del(&mm->t3210); } } static void stop_mm_t3211(struct gsm48_mmlayer *mm) { - if (bsc_timer_pending(&mm->t3211)) { + if (osmo_timer_pending(&mm->t3211)) { LOGP(DMM, LOGL_INFO, "stopping pending (loc. upd. retry " "delay) timer T3211\n"); - bsc_del_timer(&mm->t3211); + osmo_timer_del(&mm->t3211); } } static void stop_mm_t3212(struct gsm48_mmlayer *mm) { - if (bsc_timer_pending(&mm->t3212)) { + if (osmo_timer_pending(&mm->t3212)) { LOGP(DMM, LOGL_INFO, "stopping pending (periodic loc. upd. " "delay) timer T3212\n"); - bsc_del_timer(&mm->t3212); + osmo_timer_del(&mm->t3212); } } static void stop_mm_t3213(struct gsm48_mmlayer *mm) { - if (bsc_timer_pending(&mm->t3213)) { + if (osmo_timer_pending(&mm->t3213)) { LOGP(DMM, LOGL_INFO, "stopping pending (delay after RA " "failure) timer T3213\n"); - bsc_del_timer(&mm->t3213); + osmo_timer_del(&mm->t3213); } } static void stop_mm_t3220(struct gsm48_mmlayer *mm) { - if (bsc_timer_pending(&mm->t3220)) { + if (osmo_timer_pending(&mm->t3220)) { LOGP(DMM, LOGL_INFO, "stopping pending (IMSI detach keepalive) " "timer T3220\n"); - bsc_del_timer(&mm->t3220); + osmo_timer_del(&mm->t3220); } } static void stop_mm_t3230(struct gsm48_mmlayer *mm) { - if (bsc_timer_pending(&mm->t3230)) { + if (osmo_timer_pending(&mm->t3230)) { LOGP(DMM, LOGL_INFO, "stopping pending (MM connection timeout) " "timer T3230\n"); - bsc_del_timer(&mm->t3230); + osmo_timer_del(&mm->t3230); } } static void stop_mm_t3240(struct gsm48_mmlayer *mm) { - if (bsc_timer_pending(&mm->t3240)) { + if (osmo_timer_pending(&mm->t3240)) { LOGP(DMM, LOGL_INFO, "stopping pending (RR release timeout) " "timer T3240\n"); - bsc_del_timer(&mm->t3240); + osmo_timer_del(&mm->t3240); } } @@ -920,7 +920,7 @@ static void new_mm_state(struct gsm48_mmlayer *mm, int state, int substate) && (substate == GSM48_MM_SST_NORMAL_SERVICE || substate == GSM48_MM_SST_ATTEMPT_UPDATE)) { /* start periodic location update timer */ - if (!bsc_timer_pending(&mm->t3212)) + if (!osmo_timer_pending(&mm->t3212)) start_mm_t3212(mm, mm->t3212_value); /* perform pending location update */ if (mm->lupd_retry) { @@ -1954,7 +1954,7 @@ static int gsm48_mm_sysinfo(struct osmocom_ms *ms, struct msgb *msg) /* new periodic location update timer timeout */ if (s->t3212 && s->t3212 != mm->t3212_value) { - if (bsc_timer_pending(&mm->t3212)) { + if (osmo_timer_pending(&mm->t3212)) { int t; struct timeval current_time; @@ -3865,7 +3865,7 @@ static int gsm48_mm_data_ind(struct osmocom_ms *ms, struct msgb *msg) stop_mm_t3212(mm); /* 4.4.2 */ /* 11.2 re-start pending RR release timer */ - if (bsc_timer_pending(&mm->t3240)) { + if (osmo_timer_pending(&mm->t3240)) { stop_mm_t3240(mm); start_mm_t3240(mm); } diff --git a/src/host/layer23/src/mobile/gsm48_rr.c b/src/host/layer23/src/mobile/gsm48_rr.c index b2ab2e1..c1c27f4 100644 --- a/src/host/layer23/src/mobile/gsm48_rr.c +++ b/src/host/layer23/src/mobile/gsm48_rr.c @@ -711,7 +711,7 @@ static void start_rr_t_meas(struct gsm48_rrlayer *rr, int sec, int micro) { rr->t_meas.cb = timeout_rr_meas; rr->t_meas.data = rr; - bsc_schedule_timer(&rr->t_meas, sec, micro); + osmo_timer_schedule(&rr->t_meas, sec, micro); } static void start_rr_t_rel_wait(struct gsm48_rrlayer *rr, int sec, int micro) @@ -720,7 +720,7 @@ static void start_rr_t_rel_wait(struct gsm48_rrlayer *rr, int sec, int micro) micro / 1000); rr->t_rel_wait.cb = timeout_rr_t_rel_wait; rr->t_rel_wait.data = rr; - bsc_schedule_timer(&rr->t_rel_wait, sec, micro); + osmo_timer_schedule(&rr->t_rel_wait, sec, micro); } static void start_rr_t_starting(struct gsm48_rrlayer *rr, int sec, int micro) @@ -729,7 +729,7 @@ static void start_rr_t_starting(struct gsm48_rrlayer *rr, int sec, int micro) micro / 1000); rr->t_starting.cb = timeout_rr_t_starting; rr->t_starting.data = rr; - bsc_schedule_timer(&rr->t_starting, sec, micro); + osmo_timer_schedule(&rr->t_starting, sec, micro); } static void start_rr_t3110(struct gsm48_rrlayer *rr, int sec, int micro) @@ -738,7 +738,7 @@ static void start_rr_t3110(struct gsm48_rrlayer *rr, int sec, int micro) micro / 1000); rr->t3110.cb = timeout_rr_t3110; rr->t3110.data = rr; - bsc_schedule_timer(&rr->t3110, sec, micro); + osmo_timer_schedule(&rr->t3110, sec, micro); } static void start_rr_t3122(struct gsm48_rrlayer *rr, int sec, int micro) @@ -747,7 +747,7 @@ static void start_rr_t3122(struct gsm48_rrlayer *rr, int sec, int micro) micro / 1000); rr->t3122.cb = timeout_rr_t3122; rr->t3122.data = rr; - bsc_schedule_timer(&rr->t3122, sec, micro); + osmo_timer_schedule(&rr->t3122, sec, micro); } static void start_rr_t3124(struct gsm48_rrlayer *rr, int sec, int micro) @@ -756,7 +756,7 @@ static void start_rr_t3124(struct gsm48_rrlayer *rr, int sec, int micro) micro / 1000); rr->t3124.cb = timeout_rr_t3124; rr->t3124.data = rr; - bsc_schedule_timer(&rr->t3124, sec, micro); + osmo_timer_schedule(&rr->t3124, sec, micro); } static void start_rr_t3126(struct gsm48_rrlayer *rr, int sec, int micro) @@ -765,62 +765,62 @@ static void start_rr_t3126(struct gsm48_rrlayer *rr, int sec, int micro) micro / 1000); rr->t3126.cb = timeout_rr_t3126; rr->t3126.data = rr; - bsc_schedule_timer(&rr->t3126, sec, micro); + osmo_timer_schedule(&rr->t3126, sec, micro); } static void stop_rr_t_meas(struct gsm48_rrlayer *rr) { - if (bsc_timer_pending(&rr->t_meas)) { + if (osmo_timer_pending(&rr->t_meas)) { LOGP(DRR, LOGL_INFO, "stopping pending timer T_meas\n"); - bsc_del_timer(&rr->t_meas); + osmo_timer_del(&rr->t_meas); } } static void stop_rr_t_starting(struct gsm48_rrlayer *rr) { - if (bsc_timer_pending(&rr->t_starting)) { + if (osmo_timer_pending(&rr->t_starting)) { LOGP(DRR, LOGL_INFO, "stopping pending timer T_starting\n"); - bsc_del_timer(&rr->t_starting); + osmo_timer_del(&rr->t_starting); } } static void stop_rr_t_rel_wait(struct gsm48_rrlayer *rr) { - if (bsc_timer_pending(&rr->t_rel_wait)) { + if (osmo_timer_pending(&rr->t_rel_wait)) { LOGP(DRR, LOGL_INFO, "stopping pending timer T_rel_wait\n"); - bsc_del_timer(&rr->t_rel_wait); + osmo_timer_del(&rr->t_rel_wait); } } static void stop_rr_t3110(struct gsm48_rrlayer *rr) { - if (bsc_timer_pending(&rr->t3110)) { + if (osmo_timer_pending(&rr->t3110)) { LOGP(DRR, LOGL_INFO, "stopping pending timer T3110\n"); - bsc_del_timer(&rr->t3110); + osmo_timer_del(&rr->t3110); } } static void stop_rr_t3122(struct gsm48_rrlayer *rr) { - if (bsc_timer_pending(&rr->t3122)) { + if (osmo_timer_pending(&rr->t3122)) { LOGP(DRR, LOGL_INFO, "stopping pending timer T3122\n"); - bsc_del_timer(&rr->t3122); + osmo_timer_del(&rr->t3122); } } static void stop_rr_t3124(struct gsm48_rrlayer *rr) { - if (bsc_timer_pending(&rr->t3124)) { + if (osmo_timer_pending(&rr->t3124)) { LOGP(DRR, LOGL_INFO, "stopping pending timer T3124\n"); - bsc_del_timer(&rr->t3124); + osmo_timer_del(&rr->t3124); } } static void stop_rr_t3126(struct gsm48_rrlayer *rr) { - if (bsc_timer_pending(&rr->t3126)) { + if (osmo_timer_pending(&rr->t3126)) { LOGP(DRR, LOGL_INFO, "stopping pending timer T3126\n"); - bsc_del_timer(&rr->t3126); + osmo_timer_del(&rr->t3126); } } @@ -1454,7 +1454,7 @@ fail: if (!rr->n_chan_req) { LOGP(DRR, LOGL_INFO, "Done with sending RANDOM ACCESS " "bursts\n"); - if (!bsc_timer_pending(&rr->t3126)) + if (!osmo_timer_pending(&rr->t3126)) start_rr_t3126(rr, 5, 0); /* TODO improve! */ return 0; } @@ -2494,7 +2494,7 @@ static int gsm48_rr_rx_imm_ass_rej(struct osmocom_ms *ms, struct msgb *msg) if (t3122_value) start_rr_t3122(rr, t3122_value, 0); /* start timer 3126 if not already */ - if (!bsc_timer_pending(&rr->t3126)) + if (!osmo_timer_pending(&rr->t3126)) start_rr_t3126(rr, 5, 0); /* TODO improve! */ /* stop assignmnet requests */ rr->n_chan_req = 0; @@ -4232,7 +4232,7 @@ static int gsm48_rr_est_req(struct osmocom_ms *ms, struct msgb *msg) uint16_t acc_class; /* 3.3.1.1.3.2 */ - if (bsc_timer_pending(&rr->t3122)) { + if (osmo_timer_pending(&rr->t3122)) { if (rrh->cause != RR_EST_CAUSE_EMERGENCY) { LOGP(DRR, LOGL_INFO, "T3122 running, rejecting!\n"); cause = RR_REL_CAUSE_T3122; @@ -5044,7 +5044,7 @@ static int gsm48_rr_rand_acc_cnf_dedicated(struct osmocom_ms *ms, struct msgb *m } /* start timer for sending next HANDOVER ACCESS bursts afterwards */ - if (!bsc_timer_pending(&rr->t3124)) { + if (!osmo_timer_pending(&rr->t3124)) { if (allocated channel is SDCCH) start_rr_t3124(rr, GSM_T3124_675); else diff --git a/src/host/layer23/src/mobile/mnccms.c b/src/host/layer23/src/mobile/mnccms.c index 4d47be4..8d3abe6 100644 --- a/src/host/layer23/src/mobile/mnccms.c +++ b/src/host/layer23/src/mobile/mnccms.c @@ -51,14 +51,14 @@ static void start_dtmf_timer(struct gsm_call *call, uint16_t ms) LOGP(DCC, LOGL_INFO, "starting DTMF timer %d ms\n", ms); call->dtmf_timer.cb = timeout_dtmf; call->dtmf_timer.data = call; - bsc_schedule_timer(&call->dtmf_timer, 0, ms * 1000); + osmo_timer_schedule(&call->dtmf_timer, 0, ms * 1000); } static void stop_dtmf_timer(struct gsm_call *call) { - if (bsc_timer_pending(&call->dtmf_timer)) { + if (osmo_timer_pending(&call->dtmf_timer)) { LOGP(DCC, LOGL_INFO, "stopping pending DTMF timer\n"); - bsc_del_timer(&call->dtmf_timer); + osmo_timer_del(&call->dtmf_timer); } } diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index 2c42799..c8ea38a 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -164,7 +164,7 @@ struct dnload { static struct dnload dnload; -static struct timer_list tick_timer; +static struct osmo_timer_list tick_timer; /* Compal ramloader specific */ static const uint8_t phone_prompt1[] = { 0x1b, 0xf6, 0x02, 0x00, 0x41, 0x01, 0x40 }; @@ -290,7 +290,7 @@ static void beacon_timer_cb(void *p) if (!(rc == sizeof(romload_ident_cmd))) printf("Error sending identification beacon\n"); - bsc_schedule_timer(p, 0, dnload.beacon_interval); + osmo_timer_schedule(p, 0, dnload.beacon_interval); } } @@ -305,7 +305,7 @@ static void mtk_timer_cb(void *p) if (!(rc == 1)) printf("Error sending identification beacon\n"); - bsc_schedule_timer(p, 0, dnload.beacon_interval); + osmo_timer_schedule(p, 0, dnload.beacon_interval); } } @@ -889,7 +889,7 @@ static int handle_read(void) serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); tick_timer.cb = &beacon_timer_cb; tick_timer.data = &tick_timer; - bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); + osmo_timer_schedule(&tick_timer, 0, dnload.beacon_interval); } } else if (!memcmp(buffer, phone_nack, sizeof(phone_nack))) { printf("Received DOWNLOAD NACK from phone, something went" @@ -1004,7 +1004,7 @@ static int handle_read_romload(void) "something went wrong, aborting\n"); serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); dnload.romload_state = WAITING_IDENTIFICATION; - bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); + osmo_timer_schedule(&tick_timer, 0, dnload.beacon_interval); } break; case WAITING_CHECKSUM_ACK: @@ -1026,7 +1026,7 @@ static int handle_read_romload(void) "match ours, aborting\n", ~buffer[2]); serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); dnload.romload_state = WAITING_IDENTIFICATION; - bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); + osmo_timer_schedule(&tick_timer, 0, dnload.beacon_interval); bufptr -= 1; } break; @@ -1043,7 +1043,7 @@ static int handle_read_romload(void) printf("Received branch nack, aborting\n"); serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); dnload.romload_state = WAITING_IDENTIFICATION; - bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); + osmo_timer_schedule(&tick_timer, 0, dnload.beacon_interval); } break; default: @@ -1536,14 +1536,14 @@ int main(int argc, char **argv) serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); tick_timer.cb = &beacon_timer_cb; tick_timer.data = &tick_timer; - bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); + osmo_timer_schedule(&tick_timer, 0, dnload.beacon_interval); } else if (dnload.mode == MODE_MTK) { tmp_load_address = MTK_ADDRESS; serial_set_baudrate(MTK_INIT_BAUDRATE); tick_timer.cb = &mtk_timer_cb; tick_timer.data = &tick_timer; - bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); + osmo_timer_schedule(&tick_timer, 0, dnload.beacon_interval); } dnload.load_address[0] = (tmp_load_address >> 24) & 0xff; diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 6663a1e..6a31dc1 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -84,7 +84,7 @@ static struct { uint8_t command; /* general timeout */ - struct timer_list timeout; + struct osmo_timer_list timeout; /* binary i/o for firmware images */ FILE *binfile; @@ -661,7 +661,7 @@ loader_do_memload() { return; } - bsc_schedule_timer(&osmoload.timeout, 0, 500000); + osmo_timer_schedule(&osmoload.timeout, 0, 500000); uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; @@ -701,7 +701,7 @@ loader_do_fprogram() { return; } - bsc_schedule_timer(&osmoload.timeout, 0, 10000000); + osmo_timer_schedule(&osmoload.timeout, 0, 10000000); uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; @@ -1143,7 +1143,7 @@ loader_command(char *name, int cmdc, char **cmdv) { if(osmoload.state == STATE_QUERY_PENDING) { osmoload.timeout.cb = &query_timeout; - bsc_schedule_timer(&osmoload.timeout, 0, 5000000); + osmo_timer_schedule(&osmoload.timeout, 0, 5000000); } if(osmoload.state == STATE_LOAD_IN_PROGRESS) { osmoload.timeout.cb = &memop_timeout; diff --git a/src/target/firmware/comm/timer.c b/src/target/firmware/comm/timer.c index 54abc79..6a649ae 100644 --- a/src/target/firmware/comm/timer.c +++ b/src/target/firmware/comm/timer.c @@ -41,9 +41,9 @@ unsigned long volatile jiffies; ((long)(b) - (long)(a) < 0)) #define time_before(a,b) time_after(b,a) -void add_timer(struct timer_list *timer) +void add_timer(struct osmo_timer_list *timer) { - struct timer_list *list_timer; + struct osmo_timer_list *list_timer; /* TODO: Optimize and remember the closest item... */ timer->active = 1; @@ -57,13 +57,13 @@ void add_timer(struct timer_list *timer) llist_add(&timer->entry, &timer_list); } -void schedule_timer(struct timer_list *timer, int milliseconds) +void schedule_timer(struct osmo_timer_list *timer, int milliseconds) { timer->expires = jiffies + ((milliseconds * TIMER_HZ) / 1000); add_timer(timer); } -void del_timer(struct timer_list *timer) +void del_timer(struct osmo_timer_list *timer) { if (timer->in_list) { timer->active = 0; @@ -72,7 +72,7 @@ void del_timer(struct timer_list *timer) } } -int timer_pending(struct timer_list *timer) +int timer_pending(struct osmo_timer_list *timer) { return timer->active; } @@ -113,7 +113,7 @@ struct timeval *nearest_timer() */ void prepare_timers() { - struct timer_list *timer, *nearest_timer = NULL; + struct osmo_timer_list *timer, *nearest_timer = NULL; llist_for_each_entry(timer, &timer_list, entry) { if (!nearest_timer || time_before(timer->expires, nearest_timer->expires)) { nearest_timer = timer; @@ -133,7 +133,7 @@ void prepare_timers() */ int update_timers(void) { - struct timer_list *timer, *tmp; + struct osmo_timer_list *timer, *tmp; int work = 0; /* @@ -178,7 +178,7 @@ restart: int timer_check(void) { - struct timer_list *timer; + struct osmo_timer_list *timer; int i = 0; llist_for_each_entry(timer, &timer_list, entry) { diff --git a/src/target/firmware/include/comm/timer.h b/src/target/firmware/include/comm/timer.h index 42bf734..db7d1a5 100644 --- a/src/target/firmware/include/comm/timer.h +++ b/src/target/firmware/include/comm/timer.h @@ -27,7 +27,7 @@ /** * Timer management: - * - Create a struct timer_list + * - Create a struct osmo_timer_list * - Fill out timeout and use add_timer or * use schedule_timer to schedule a timer in * x seconds and microseconds from now... @@ -41,7 +41,7 @@ * the timers. * */ -struct timer_list { +struct osmo_timer_list { struct llist_head entry; unsigned long expires; @@ -58,10 +58,10 @@ extern unsigned long volatile jiffies; /** * timer management */ -void add_timer(struct timer_list *timer); -void schedule_timer(struct timer_list *timer, int miliseconds); -void del_timer(struct timer_list *timer); -int timer_pending(struct timer_list *timer); +void add_timer(struct osmo_timer_list *timer); +void schedule_timer(struct osmo_timer_list *timer, int miliseconds); +void del_timer(struct osmo_timer_list *timer); +int timer_pending(struct osmo_timer_list *timer); /** -- 1.7.2.3 From pablo at gnumonks.org Sun May 15 13:14:22 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sun, 15 May 2011 15:14:22 +0200 Subject: [PATCH 2/6] src: use namespace prefix osmo_fd* and osmo_select* In-Reply-To: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> Message-ID: <1305465266-18081-3-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Summary of changes: s/struct bsc_fd/struct osmo_fd/g s/bsc_register_fd/osmo_fd_register/g s/bsc_unregister_fd/osmo_fd_unregister/g s/bsc_select_main/osmo_select_main/g --- src/host/layer23/src/common/gps.c | 14 +++++++------- src/host/layer23/src/common/l1l2_interface.c | 8 ++++---- src/host/layer23/src/common/main.c | 2 +- src/host/layer23/src/common/sap_interface.c | 8 ++++---- src/host/layer23/src/mobile/main.c | 2 +- src/host/osmocon/osmocon.c | 24 ++++++++++++------------ src/host/osmocon/osmoload.c | 10 +++++----- 7 files changed, 34 insertions(+), 34 deletions(-) diff --git a/src/host/layer23/src/common/gps.c b/src/host/layer23/src/common/gps.c index dba93fb..38aae2c 100644 --- a/src/host/layer23/src/common/gps.c +++ b/src/host/layer23/src/common/gps.c @@ -52,13 +52,13 @@ struct osmo_gps g = { 0,0 }; -static struct bsc_fd gps_bfd; +static struct osmo_fd gps_bfd; #ifdef _HAVE_GPSD static struct gps_data_t* gdata; -int osmo_gpsd_cb(struct bsc_fd *bfd, unsigned int what) +int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what) { struct tm *tm; unsigned diff = 0; @@ -125,7 +125,7 @@ int osmo_gpsd_open(void) return -1; } - bsc_register_fd(&gps_bfd); + osmo_fd_register(&gps_bfd); return 0; } @@ -137,7 +137,7 @@ void osmo_gpsd_close(void) LOGP(DGPS, LOGL_INFO, "Disconnecting from gpsd\n"); - bsc_unregister_fd(&gps_bfd); + osmo_fd_unregister(&gps_bfd); gps_close(gdata); gps_bfd.fd = -1; /* -1 or 0 indicates: 'close' */ @@ -242,7 +242,7 @@ static int nmea_checksum(char *line) return (strtoul(line+1, NULL, 16) == checksum); } -int osmo_serialgps_cb(struct bsc_fd *bfd, unsigned int what) +int osmo_serialgps_cb(struct osmo_fd *bfd, unsigned int what) { char buff[128]; static char line[128]; @@ -323,7 +323,7 @@ int osmo_serialgps_open(void) printf("Failed to set termios for GPS\n"); } - bsc_register_fd(&gps_bfd); + osmo_fd_register(&gps_bfd); return 0; } @@ -335,7 +335,7 @@ void osmo_serialgps_close(void) LOGP(DGPS, LOGL_INFO, "Close GPS device\n"); - bsc_unregister_fd(&gps_bfd); + osmo_fd_unregister(&gps_bfd); if (isatty(gps_bfd.fd)) tcsetattr(gps_bfd.fd, TCSANOW, &gps_old_termios); diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index 23e1ef2..3272359 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -42,7 +42,7 @@ #define GSM_L2_LENGTH 256 #define GSM_L2_HEADROOM 32 -static int layer2_read(struct bsc_fd *fd) +static int layer2_read(struct osmo_fd *fd) { struct msgb *msg; u_int16_t len; @@ -86,7 +86,7 @@ static int layer2_read(struct bsc_fd *fd) return 0; } -static int layer2_write(struct bsc_fd *fd, struct msgb *msg) +static int layer2_write(struct osmo_fd *fd, struct msgb *msg) { int rc; @@ -132,7 +132,7 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) ms->l2_wq.read_cb = layer2_read; ms->l2_wq.write_cb = layer2_write; - rc = bsc_register_fd(&ms->l2_wq.bfd); + rc = osmo_fd_register(&ms->l2_wq.bfd); if (rc != 0) { fprintf(stderr, "Failed to register fd.\n"); close(ms->l2_wq.bfd.fd); @@ -149,7 +149,7 @@ int layer2_close(struct osmocom_ms *ms) close(ms->l2_wq.bfd.fd); ms->l2_wq.bfd.fd = -1; - bsc_unregister_fd(&ms->l2_wq.bfd); + osmo_fd_unregister(&ms->l2_wq.bfd); return 0; } diff --git a/src/host/layer23/src/common/main.c b/src/host/layer23/src/common/main.c index 61513ea..40e6a07 100644 --- a/src/host/layer23/src/common/main.c +++ b/src/host/layer23/src/common/main.c @@ -278,7 +278,7 @@ int main(int argc, char **argv) while (!quit) { if (l23_app_work) l23_app_work(ms); - bsc_select_main(0); + osmo_select_main(0); } return 0; diff --git a/src/host/layer23/src/common/sap_interface.c b/src/host/layer23/src/common/sap_interface.c index 54aa635..4d465f0 100644 --- a/src/host/layer23/src/common/sap_interface.c +++ b/src/host/layer23/src/common/sap_interface.c @@ -42,7 +42,7 @@ #define GSM_SAP_LENGTH 300 #define GSM_SAP_HEADROOM 32 -static int sap_read(struct bsc_fd *fd) +static int sap_read(struct osmo_fd *fd) { struct msgb *msg; u_int16_t len; @@ -88,7 +88,7 @@ static int sap_read(struct bsc_fd *fd) return 0; } -static int sap_write(struct bsc_fd *fd, struct msgb *msg) +static int sap_write(struct osmo_fd *fd, struct msgb *msg) { int rc; @@ -133,7 +133,7 @@ int sap_open(struct osmocom_ms *ms, const char *socket_path) ms->sap_wq.read_cb = sap_read; ms->sap_wq.write_cb = sap_write; - rc = bsc_register_fd(&ms->sap_wq.bfd); + rc = osmo_fd_register(&ms->sap_wq.bfd); if (rc != 0) { fprintf(stderr, "Failed to register fd.\n"); return rc; @@ -149,7 +149,7 @@ int sap_close(struct osmocom_ms *ms) close(ms->sap_wq.bfd.fd); ms->sap_wq.bfd.fd = -1; - bsc_unregister_fd(&ms->sap_wq.bfd); + osmo_fd_unregister(&ms->sap_wq.bfd); return 0; } diff --git a/src/host/layer23/src/mobile/main.c b/src/host/layer23/src/mobile/main.c index 4765995..1f423a2 100644 --- a/src/host/layer23/src/mobile/main.c +++ b/src/host/layer23/src/mobile/main.c @@ -202,7 +202,7 @@ int main(int argc, char **argv) l23_app_work(&quit); if (quit && llist_empty(&ms_list)) break; - bsc_select_main(0); + osmo_select_main(0); } l23_app_exit(); diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index c8ea38a..ab977c1 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -69,14 +69,14 @@ struct tool_server *tool_server_for_dlci[256]; struct tool_connection { struct tool_server *server; struct llist_head entry; - struct bsc_fd fd; + struct osmo_fd fd; }; /** * server for a tool */ struct tool_server { - struct bsc_fd bfd; + struct osmo_fd bfd; uint8_t dlci; struct llist_head connections; }; @@ -129,7 +129,7 @@ struct dnload { enum romload_state romload_state; enum mtk_state mtk_state; enum dnload_mode mode; - struct bsc_fd serial_fd; + struct osmo_fd serial_fd; char *filename; char *chainload_filename; @@ -1192,7 +1192,7 @@ static int handle_read_mtk(void) return nbytes; } -static int serial_read(struct bsc_fd *fd, unsigned int flags) +static int serial_read(struct osmo_fd *fd, unsigned int flags) { int rc; if (flags & BSC_FD_READ) { @@ -1264,7 +1264,7 @@ static int version(const char *name) exit(2); } -static int un_tool_read(struct bsc_fd *fd, unsigned int flags) +static int un_tool_read(struct osmo_fd *fd, unsigned int flags) { int rc, c; uint16_t length = 0xffff; @@ -1313,14 +1313,14 @@ static int un_tool_read(struct bsc_fd *fd, unsigned int flags) close: close(fd->fd); - bsc_unregister_fd(fd); + osmo_fd_unregister(fd); llist_del(&con->entry); talloc_free(con); return -1; } /* accept a new connection */ -static int tool_accept(struct bsc_fd *fd, unsigned int flags) +static int tool_accept(struct osmo_fd *fd, unsigned int flags) { struct tool_server *srv = (struct tool_server *)fd->data; struct tool_connection *con; @@ -1347,7 +1347,7 @@ static int tool_accept(struct bsc_fd *fd, unsigned int flags) con->fd.when = BSC_FD_READ; con->fd.cb = un_tool_read; con->fd.data = con; - if (bsc_register_fd(&con->fd) != 0) { + if (osmo_fd_register(&con->fd) != 0) { fprintf(stderr, "Failed to register the fd.\n"); return -1; } @@ -1363,7 +1363,7 @@ static int register_tool_server(struct tool_server *ts, const char *path, uint8_t dlci) { - struct bsc_fd *bfd = &ts->bfd; + struct osmo_fd *bfd = &ts->bfd; struct sockaddr_un local; unsigned int namelen; int rc; @@ -1415,7 +1415,7 @@ static int register_tool_server(struct tool_server *ts, sercomm_register_rx_cb(dlci, hdlc_tool_cb); - if (bsc_register_fd(bfd) != 0) { + if (osmo_fd_register(bfd) != 0) { fprintf(stderr, "Failed to register the bfd.\n"); return -1; } @@ -1503,7 +1503,7 @@ int main(int argc, char **argv) exit(1); } - if (bsc_register_fd(&dnload.serial_fd) != 0) { + if (osmo_fd_register(&dnload.serial_fd) != 0) { fprintf(stderr, "Failed to register the serial.\n"); exit(1); } @@ -1552,7 +1552,7 @@ int main(int argc, char **argv) dnload.load_address[3] = tmp_load_address & 0xff; while (1) - bsc_select_main(0); + osmo_select_main(0); close(dnload.serial_fd.fd); diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 6a31dc1..1471a2e 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -48,7 +48,7 @@ #define DEFAULT_SOCKET "/tmp/osmocom_loader" -static struct bsc_fd connection; +static struct osmo_fd connection; enum { STATE_INIT, @@ -451,7 +451,7 @@ loader_handle_reply(struct msgb *msg) { } static int -loader_read_cb(struct bsc_fd *fd, unsigned int flags) { +loader_read_cb(struct osmo_fd *fd, unsigned int flags) { struct msgb *msg; u_int16_t len; int rc; @@ -494,7 +494,7 @@ static void loader_connect(const char *socket_path) { int rc; struct sockaddr_un local; - struct bsc_fd *conn = &connection; + struct osmo_fd *conn = &connection; local.sun_family = AF_UNIX; strncpy(local.sun_path, socket_path, sizeof(local.sun_path)); @@ -517,7 +517,7 @@ loader_connect(const char *socket_path) { conn->cb = loader_read_cb; conn->data = NULL; - if (bsc_register_fd(conn) != 0) { + if (osmo_fd_register(conn) != 0) { fprintf(stderr, "Failed to register fd.\n"); exit(1); } @@ -1205,7 +1205,7 @@ main(int argc, char **argv) { loader_command(argv[0], argc - optind, argv + optind); while(!osmoload.quit) { - bsc_select_main(0); + osmo_select_main(0); } if(osmoload.binfile) { -- 1.7.2.3 From pablo at gnumonks.org Sun May 15 13:14:23 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sun, 15 May 2011 15:14:23 +0200 Subject: [PATCH 3/6] src: use namespace prefix osmo_signal* In-Reply-To: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> Message-ID: <1305465266-18081-4-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Summary of changes: s/signal_cbfn/osmo_signal_cbfn/g s/register_signal_handler/osmo_signal_register_handler/g s/unregister_signal_handler/osmo_signal_unregister_handler/g s/dispatch_signal/osmo_signal_dispatch/g --- src/host/layer23/src/common/l1ctl.c | 18 +++++++++--------- src/host/layer23/src/misc/app_bcch_scan.c | 2 +- src/host/layer23/src/misc/app_cbch_sniff.c | 2 +- src/host/layer23/src/misc/app_ccch_scan.c | 2 +- src/host/layer23/src/misc/bcch_scan.c | 2 +- src/host/layer23/src/misc/cell_log.c | 4 ++-- src/host/layer23/src/mobile/app_mobile.c | 12 ++++++------ src/host/layer23/src/mobile/main.c | 2 +- src/host/layer23/src/mobile/vty_interface.c | 2 +- 9 files changed, 23 insertions(+), 23 deletions(-) diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c index f2714e6..a2fd865 100644 --- a/src/host/layer23/src/common/l1ctl.c +++ b/src/host/layer23/src/common/l1ctl.c @@ -92,7 +92,7 @@ static int rx_l1_fbsb_conf(struct osmocom_ms *ms, struct msgb *msg) if (sb->result != 0) { LOGP(DL1C, LOGL_ERROR, "FBSB RESP: result=%u\n", sb->result); - dispatch_signal(SS_L1CTL, S_L1CTL_FBSB_ERR, ms); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_FBSB_ERR, ms); return 0; } @@ -102,7 +102,7 @@ static int rx_l1_fbsb_conf(struct osmocom_ms *ms, struct msgb *msg) fr.ms = ms; fr.snr = dl->snr; fr.bsic = sb->bsic; - dispatch_signal(SS_L1CTL, S_L1CTL_FBSB_RESP, &fr); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_FBSB_RESP, &fr); return 0; } @@ -177,7 +177,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) if (meas->dsc > 0) break; meas->ds_fail = 0; - dispatch_signal(SS_L1CTL, S_L1CTL_LOSS_IND, ms); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_LOSS_IND, ms); break; } } else { @@ -199,7 +199,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) if (meas->s > 0) break; meas->rl_fail = 0; - dispatch_signal(SS_L1CTL, S_L1CTL_LOSS_IND, ms); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_LOSS_IND, ms); break; } } @@ -656,7 +656,7 @@ int l1ctl_tx_reset_req(struct osmocom_ms *ms, uint8_t type) static int rx_l1_reset(struct osmocom_ms *ms) { LOGP(DL1C, LOGL_INFO, "Layer1 Reset indication\n"); - dispatch_signal(SS_L1CTL, S_L1CTL_RESET, ms); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_RESET, ms); return 0; } @@ -674,7 +674,7 @@ static int rx_l1_pm_conf(struct osmocom_ms *ms, struct msgb *msg) mr.band_arfcn = ntohs(pmr->band_arfcn); mr.rx_lev = pmr->pm[0]; mr.ms = ms; - dispatch_signal(SS_L1CTL, S_L1CTL_PM_RES, &mr); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_PM_RES, &mr); } return 0; } @@ -697,7 +697,7 @@ static int rx_l1_ccch_mode_conf(struct osmocom_ms *ms, struct msgb *msg) mc.ccch_mode = conf->ccch_mode; mc.ms = ms; - dispatch_signal(SS_L1CTL, S_L1CTL_CCCH_MODE_CONF, &mc); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_CCCH_MODE_CONF, &mc); return 0; } @@ -720,7 +720,7 @@ static int rx_l1_tch_mode_conf(struct osmocom_ms *ms, struct msgb *msg) mc.tch_mode = conf->tch_mode; mc.ms = ms; - dispatch_signal(SS_L1CTL, S_L1CTL_TCH_MODE_CONF, &mc); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_TCH_MODE_CONF, &mc); return 0; } @@ -764,7 +764,7 @@ int l1ctl_recv(struct osmocom_ms *ms, struct msgb *msg) case L1CTL_PM_CONF: rc = rx_l1_pm_conf(ms, msg); if (l1h->flags & L1CTL_F_DONE) - dispatch_signal(SS_L1CTL, S_L1CTL_PM_DONE, ms); + osmo_signal_dispatch(SS_L1CTL, S_L1CTL_PM_DONE, ms); msgb_free(msg); break; case L1CTL_RACH_CONF: diff --git a/src/host/layer23/src/misc/app_bcch_scan.c b/src/host/layer23/src/misc/app_bcch_scan.c index 9a01694..3ad426d 100644 --- a/src/host/layer23/src/misc/app_bcch_scan.c +++ b/src/host/layer23/src/misc/app_bcch_scan.c @@ -54,7 +54,7 @@ int l23_app_init(struct osmocom_ms *ms) /* don't do layer3_init() as we don't want an actualy L3 */ fps_init(ms); l1ctl_tx_reset_req(ms, L1CTL_RES_T_FULL); - return register_signal_handler(SS_L1CTL, &signal_cb, NULL); + return osmo_signal_register_handler(SS_L1CTL, &signal_cb, NULL); } static struct l23_app_info info = { diff --git a/src/host/layer23/src/misc/app_cbch_sniff.c b/src/host/layer23/src/misc/app_cbch_sniff.c index 77427fa..2df1e54 100644 --- a/src/host/layer23/src/misc/app_cbch_sniff.c +++ b/src/host/layer23/src/misc/app_cbch_sniff.c @@ -185,7 +185,7 @@ int l23_app_init(struct osmocom_ms *ms) /* FIXME: L1CTL_RES_T_FULL doesn't reset dedicated mode * (if previously set), so we release it here. */ l1ctl_tx_dm_rel_req(ms); - return register_signal_handler(SS_L1CTL, &signal_cb, NULL); + return osmo_signal_register_handler(SS_L1CTL, &signal_cb, NULL); } static struct l23_app_info info = { diff --git a/src/host/layer23/src/misc/app_ccch_scan.c b/src/host/layer23/src/misc/app_ccch_scan.c index 913ceca..02b5e47 100644 --- a/src/host/layer23/src/misc/app_ccch_scan.c +++ b/src/host/layer23/src/misc/app_ccch_scan.c @@ -465,7 +465,7 @@ static int signal_cb(unsigned int subsys, unsigned int signal, int l23_app_init(struct osmocom_ms *ms) { - register_signal_handler(SS_L1CTL, &signal_cb, NULL); + osmo_signal_register_handler(SS_L1CTL, &signal_cb, NULL); l1ctl_tx_reset_req(ms, L1CTL_RES_T_FULL); return layer3_init(ms); } diff --git a/src/host/layer23/src/misc/bcch_scan.c b/src/host/layer23/src/misc/bcch_scan.c index fc88254..ddd0eea 100644 --- a/src/host/layer23/src/misc/bcch_scan.c +++ b/src/host/layer23/src/misc/bcch_scan.c @@ -314,5 +314,5 @@ int fps_start(struct osmocom_ms *ms) int fps_init(void) { - return register_signal_handler(SS_L1CTL, &bscan_sig_cb, NULL); + return osmo_signal_register_handler(SS_L1CTL, &bscan_sig_cb, NULL); } diff --git a/src/host/layer23/src/misc/cell_log.c b/src/host/layer23/src/misc/cell_log.c index a1a764b..3f51f87 100644 --- a/src/host/layer23/src/misc/cell_log.c +++ b/src/host/layer23/src/misc/cell_log.c @@ -783,7 +783,7 @@ static int rcv_rsl(struct msgb *msg, struct osmocom_ms *ms) int scan_init(struct osmocom_ms *_ms) { ms = _ms; - register_signal_handler(SS_L1CTL, &signal_cb, NULL); + osmo_signal_register_handler(SS_L1CTL, &signal_cb, NULL); memset(&timer, 0, sizeof(timer)); osmol2_register_handler(ms, &rcv_rsl); g.enable = 1; @@ -812,7 +812,7 @@ int scan_exit(void) osmo_gps_close(); if (logfp) fclose(logfp); - unregister_signal_handler(SS_L1CTL, &signal_cb, NULL); + osmo_signal_unregister_handler(SS_L1CTL, &signal_cb, NULL); stop_timer(); return 0; diff --git a/src/host/layer23/src/mobile/app_mobile.c b/src/host/layer23/src/mobile/app_mobile.c index 33fdde6..e37ac98 100644 --- a/src/host/layer23/src/mobile/app_mobile.c +++ b/src/host/layer23/src/mobile/app_mobile.c @@ -329,9 +329,9 @@ int l23_app_work(int *_quit) /* global exit */ int l23_app_exit(void) { - unregister_signal_handler(SS_L1CTL, &gsm322_l1_signal, NULL); - unregister_signal_handler(SS_L1CTL, &mobile_signal_cb, NULL); - unregister_signal_handler(SS_GLOBAL, &global_signal_cb, NULL); + osmo_signal_unregister_handler(SS_L1CTL, &gsm322_l1_signal, NULL); + osmo_signal_unregister_handler(SS_L1CTL, &mobile_signal_cb, NULL); + osmo_signal_unregister_handler(SS_GLOBAL, &global_signal_cb, NULL); osmo_gps_close(); @@ -375,9 +375,9 @@ int l23_app_init(int (*mncc_recv)(struct osmocom_ms *ms, int, void *), return rc; printf("VTY available on port %u.\n", vty_port); - register_signal_handler(SS_GLOBAL, &global_signal_cb, NULL); - register_signal_handler(SS_L1CTL, &mobile_signal_cb, NULL); - register_signal_handler(SS_L1CTL, &gsm322_l1_signal, NULL); + osmo_signal_register_handler(SS_GLOBAL, &global_signal_cb, NULL); + osmo_signal_register_handler(SS_L1CTL, &mobile_signal_cb, NULL); + osmo_signal_register_handler(SS_L1CTL, &gsm322_l1_signal, NULL); if (llist_empty(&ms_list)) { struct osmocom_ms *ms; diff --git a/src/host/layer23/src/mobile/main.c b/src/host/layer23/src/mobile/main.c index 1f423a2..1f15669 100644 --- a/src/host/layer23/src/mobile/main.c +++ b/src/host/layer23/src/mobile/main.c @@ -140,7 +140,7 @@ void sighandler(int sigset) signal(SIGTERM, SIG_DFL); signal(SIGPIPE, SIG_DFL); - dispatch_signal(SS_GLOBAL, S_GLOBAL_SHUTDOWN, NULL); + osmo_signal_dispatch(SS_GLOBAL, S_GLOBAL_SHUTDOWN, NULL); } int main(int argc, char **argv) diff --git a/src/host/layer23/src/mobile/vty_interface.c b/src/host/layer23/src/mobile/vty_interface.c index 418c3f6..debe36e 100644 --- a/src/host/layer23/src/mobile/vty_interface.c +++ b/src/host/layer23/src/mobile/vty_interface.c @@ -2266,7 +2266,7 @@ gDEFUN(ournode_end, DEFUN(off, off_cmd, "off", "Turn mobiles off (shutdown) and exit") { - dispatch_signal(SS_GLOBAL, S_GLOBAL_SHUTDOWN, NULL); + osmo_signal_dispatch(SS_GLOBAL, S_GLOBAL_SHUTDOWN, NULL); return CMD_SUCCESS; } -- 1.7.2.3 From pablo at gnumonks.org Sun May 15 13:14:24 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sun, 15 May 2011 15:14:24 +0200 Subject: [PATCH 4/6] src: use namespace prefix osmo_wqueue* In-Reply-To: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> Message-ID: <1305465266-18081-5-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Summary of changes: s/struct write_queue/struct osmo_wqueue/g s/write_queue_init/osmo_wqueue_init/g s/void write_queue_clear/osmo_wqueue_clear/g s/write_queue_enqueue/osmo_wqueue_enqueue/g s/write_queue_bfd_cb/osmo_wqueue_bfd_cb/g --- .../include/osmocom/bb/common/osmocom_data.h | 2 +- src/host/layer23/src/common/l1l2_interface.c | 4 ++-- src/host/layer23/src/common/sap_interface.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h index 9d8a030..9ca4114 100644 --- a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h +++ b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h @@ -50,7 +50,7 @@ struct rx_meas_stat { struct osmocom_ms { struct llist_head entity; char name[32]; - struct write_queue l2_wq, sap_wq; + struct osmo_wqueue l2_wq, sap_wq; uint16_t test_arfcn; uint8_t deleting, shutdown, started; diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index 3272359..2abb660 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -126,7 +126,7 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->l2_wq, 100); + osmo_wqueue_init(&ms->l2_wq, 100); ms->l2_wq.bfd.data = ms; ms->l2_wq.bfd.when = BSC_FD_READ; ms->l2_wq.read_cb = layer2_read; @@ -167,7 +167,7 @@ int osmo_send_l1(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->l2_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->l2_wq, msg) != 0) { LOGP(DL1C, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; diff --git a/src/host/layer23/src/common/sap_interface.c b/src/host/layer23/src/common/sap_interface.c index 4d465f0..5d92840 100644 --- a/src/host/layer23/src/common/sap_interface.c +++ b/src/host/layer23/src/common/sap_interface.c @@ -127,7 +127,7 @@ int sap_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->sap_wq, 100); + osmo_wqueue_init(&ms->sap_wq, 100); ms->sap_wq.bfd.data = ms; ms->sap_wq.bfd.when = BSC_FD_READ; ms->sap_wq.read_cb = sap_read; @@ -170,7 +170,7 @@ int osmosap_send(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->sap_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->sap_wq, msg) != 0) { LOGP(DSAP, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; -- 1.7.2.3 From holger at freyther.de Sun May 15 14:09:28 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 15 May 2011 16:09:28 +0200 Subject: [PATCH 4/6] src: use namespace prefix osmo_wqueue* In-Reply-To: <1305465266-18081-5-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> <1305465266-18081-5-git-send-email-pablo@gnumonks.org> Message-ID: <4DCFDE98.50403@freyther.de> On 05/15/2011 03:14 PM, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > > s/void write_queue_clear/osmo_wqueue_clear/g I converted my OpenBSC (on-waves/bsc-master) branch with a sed script and I think the 'void ' here is wrong. :) From pablo at gnumonks.org Sun May 15 15:35:50 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 15 May 2011 17:35:50 +0200 Subject: [PATCH 4/6] src: use namespace prefix osmo_wqueue* In-Reply-To: <4DCFDE98.50403@freyther.de> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> <1305465266-18081-5-git-send-email-pablo@gnumonks.org> <4DCFDE98.50403@freyther.de> Message-ID: <4DCFF2D6.1090000@gnumonks.org> On 15/05/11 16:09, Holger Hans Peter Freyther wrote: > On 05/15/2011 03:14 PM, pablo at gnumonks.org wrote: >> From: Pablo Neira Ayuso >> > >> s/void write_queue_clear/osmo_wqueue_clear/g > > I converted my OpenBSC (on-waves/bsc-master) branch with a sed script and I > think the 'void ' here is wrong. :) Indeed, this has slipped through :-). I have fixed it in my osmocombb's pablo/namespace branch. New patch attached with fixed description. From pablo at gnumonks.org Sun May 15 12:45:08 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 15 May 2011 14:45:08 +0200 Subject: [PATCH] src: use namespace prefix osmo_* for crc16 functions Message-ID: Summary of changes: s/crc16_table/osmo_crc16_table/g s/crc16/osmo_crc16/g s/crc16_byte/osmo_crc16_byte/g --- src/host/osmocon/osmoload.c | 8 ++++---- src/target/firmware/apps/loader/main.c | 6 +++--- src/target/firmware/apps/loader_mtk/main.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 5848e56..8a0b21c 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -575,7 +575,7 @@ loader_start_memput(uint8_t length, uint32_t address, void *data) { struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); msgb_put_u8(msg, LOADER_MEM_WRITE); msgb_put_u8(msg, length); - msgb_put_u16(msg, crc16(0, data, length)); + msgb_put_u16(msg, osmo_crc16(0, data, length)); msgb_put_u32(msg, address); memcpy(msgb_put(msg, length), data, length); loader_send_request(msg); @@ -603,7 +603,7 @@ loader_do_memdump(uint16_t crc, void *data, size_t length) { int rc; if(data && length) { - osmoload.memcrc = crc16(0, data, length); + osmoload.memcrc = osmo_crc16(0, data, length); if(osmoload.memcrc != crc) { osmoload.memoff -= osmoload.memreq; printf("\nbad crc %4.4x (not %4.4x) at offset 0x%8.8x", crc, osmoload.memcrc, osmoload.memoff); @@ -665,7 +665,7 @@ loader_do_memload() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); @@ -705,7 +705,7 @@ loader_do_fprogram() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index a948934..2ff6f9c 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -253,7 +253,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -274,7 +274,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -392,7 +392,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 899d765..9bfaa7e 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -194,7 +194,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -215,7 +215,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -333,7 +333,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); -- 1.7.2.5 --------------090200050301070809080105-- From pablo at gnumonks.org Sun May 15 15:38:24 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 15 May 2011 17:38:24 +0200 Subject: [PATCH 4/6] src: use namespace prefix osmo_wqueue* In-Reply-To: <4DCFF2D6.1090000@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> <1305465266-18081-5-git-send-email-pablo@gnumonks.org> <4DCFDE98.50403@freyther.de> <4DCFF2D6.1090000@gnumonks.org> Message-ID: <4DCFF370.90509@gnumonks.org> On 15/05/11 17:35, Pablo Neira Ayuso wrote: > On 15/05/11 16:09, Holger Hans Peter Freyther wrote: >> On 05/15/2011 03:14 PM, pablo at gnumonks.org wrote: >>> From: Pablo Neira Ayuso >>> >> >>> s/void write_queue_clear/osmo_wqueue_clear/g >> >> I converted my OpenBSC (on-waves/bsc-master) branch with a sed script and I >> think the 'void ' here is wrong. :) > > Indeed, this has slipped through :-). > > I have fixed it in my osmocombb's pablo/namespace branch. > > New patch attached with fixed description. woops, wrong patch, here it is. From pablo at gnumonks.org Sun May 15 12:23:14 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 15 May 2011 14:23:14 +0200 Subject: [PATCH] src: use namespace prefix osmo_wqueue* Message-ID: Summary of changes: s/struct write_queue/struct osmo_wqueue/g s/write_queue_init/osmo_wqueue_init/g s/write_queue_clear/osmo_wqueue_clear/g s/write_queue_enqueue/osmo_wqueue_enqueue/g s/write_queue_bfd_cb/osmo_wqueue_bfd_cb/g --- .../include/osmocom/bb/common/osmocom_data.h | 2 +- src/host/layer23/src/common/l1l2_interface.c | 4 ++-- src/host/layer23/src/common/sap_interface.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h index 9d8a030..9ca4114 100644 --- a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h +++ b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h @@ -50,7 +50,7 @@ struct rx_meas_stat { struct osmocom_ms { struct llist_head entity; char name[32]; - struct write_queue l2_wq, sap_wq; + struct osmo_wqueue l2_wq, sap_wq; uint16_t test_arfcn; uint8_t deleting, shutdown, started; diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index 3272359..2abb660 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -126,7 +126,7 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->l2_wq, 100); + osmo_wqueue_init(&ms->l2_wq, 100); ms->l2_wq.bfd.data = ms; ms->l2_wq.bfd.when = BSC_FD_READ; ms->l2_wq.read_cb = layer2_read; @@ -167,7 +167,7 @@ int osmo_send_l1(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->l2_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->l2_wq, msg) != 0) { LOGP(DL1C, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; diff --git a/src/host/layer23/src/common/sap_interface.c b/src/host/layer23/src/common/sap_interface.c index 4d465f0..5d92840 100644 --- a/src/host/layer23/src/common/sap_interface.c +++ b/src/host/layer23/src/common/sap_interface.c @@ -127,7 +127,7 @@ int sap_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->sap_wq, 100); + osmo_wqueue_init(&ms->sap_wq, 100); ms->sap_wq.bfd.data = ms; ms->sap_wq.bfd.when = BSC_FD_READ; ms->sap_wq.read_cb = sap_read; @@ -170,7 +170,7 @@ int osmosap_send(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->sap_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->sap_wq, msg) != 0) { LOGP(DSAP, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; -- 1.7.2.5 --------------080404070907070702060601-- From pablo at gnumonks.org Sun May 15 13:14:25 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sun, 15 May 2011 15:14:25 +0200 Subject: [PATCH 5/6] src: use namespace prefix osmo_* for utils In-Reply-To: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> Message-ID: <1305465266-18081-6-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Summary of changes: s/bcd2char/osmo_bcd2char/g s/char2bcd/osmo_char2bcd/g s/hexparse/osmo_hexparse/g s/hexdump/osmo_hexdump/g s/hexdump_nospc/osmo_hexdump_nospc/g s/ubit_dump/osmo_ubit_dump/g s/static_assert/osmo_static_assert/g --- src/host/layer23/src/common/l1ctl.c | 6 +++--- src/host/layer23/src/common/l1l2_interface.c | 2 +- src/host/layer23/src/common/sap_interface.c | 2 +- src/host/layer23/src/misc/app_cbch_sniff.c | 2 +- src/host/layer23/src/mobile/vty_interface.c | 4 ++-- src/host/osmocon/osmocon.c | 8 ++++---- src/host/osmocon/osmoload.c | 10 +++++----- 7 files changed, 17 insertions(+), 17 deletions(-) diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c index a2fd865..2482c61 100644 --- a/src/host/layer23/src/common/l1ctl.c +++ b/src/host/layer23/src/common/l1ctl.c @@ -152,7 +152,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) DEBUGP(DL1C, "%s (%.4u/%.2u/%.2u) %d dBm: %s\n", rsl_chan_nr_str(dl->chan_nr), tm.t1, tm.t2, tm.t3, (int)dl->rx_level-110, - hexdump(ccch->data, sizeof(ccch->data))); + osmo_hexdump(ccch->data, sizeof(ccch->data))); meas->last_fn = ntohl(dl->frame_nr); meas->frames++; @@ -266,7 +266,7 @@ int l1ctl_tx_data_req(struct osmocom_ms *ms, struct msgb *msg, uint8_t chan_type, chan_ts, chan_ss; uint8_t gsmtap_chan_type; - DEBUGP(DL1C, "(%s)\n", hexdump(msg->l2h, msgb_l2len(msg))); + DEBUGP(DL1C, "(%s)\n", osmo_hexdump(msg->l2h, msgb_l2len(msg))); if (msgb_l2len(msg) > 23) { LOGP(DL1C, LOGL_ERROR, "L1 cannot handle message length " @@ -604,7 +604,7 @@ static int rx_l1_sim_conf(struct osmocom_ms *ms, struct msgb *msg) uint16_t len = msg->len - sizeof(struct l1ctl_hdr); uint8_t *data = msg->data + sizeof(struct l1ctl_hdr); - LOGP(DL1C, LOGL_INFO, "SIM %s\n", hexdump(data, len)); + LOGP(DL1C, LOGL_INFO, "SIM %s\n", osmo_hexdump(data, len)); /* pull the L1 header from the msgb */ msgb_pull(msg, sizeof(struct l1ctl_hdr)); diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index 2abb660..abaa64f 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -158,7 +158,7 @@ int osmo_send_l1(struct osmocom_ms *ms, struct msgb *msg) { uint16_t *len; - DEBUGP(DL1C, "Sending: '%s'\n", hexdump(msg->data, msg->len)); + DEBUGP(DL1C, "Sending: '%s'\n", osmo_hexdump(msg->data, msg->len)); if (msg->l1h != msg->data) LOGP(DL1C, LOGL_ERROR, "Message L1 header != Message Data\n"); diff --git a/src/host/layer23/src/common/sap_interface.c b/src/host/layer23/src/common/sap_interface.c index 5d92840..fd5cdc3 100644 --- a/src/host/layer23/src/common/sap_interface.c +++ b/src/host/layer23/src/common/sap_interface.c @@ -161,7 +161,7 @@ int osmosap_send(struct osmocom_ms *ms, struct msgb *msg) if (ms->sap_wq.bfd.fd <= 0) return -EINVAL; - DEBUGP(DSAP, "Sending: '%s'\n", hexdump(msg->data, msg->len)); + DEBUGP(DSAP, "Sending: '%s'\n", osmo_hexdump(msg->data, msg->len)); if (msg->l1h != msg->data) LOGP(DSAP, LOGL_ERROR, "Message SAP header != Message Data\n"); diff --git a/src/host/layer23/src/misc/app_cbch_sniff.c b/src/host/layer23/src/misc/app_cbch_sniff.c index 2df1e54..bda9aae 100644 --- a/src/host/layer23/src/misc/app_cbch_sniff.c +++ b/src/host/layer23/src/misc/app_cbch_sniff.c @@ -52,7 +52,7 @@ static int try_cbch(struct osmocom_ms *ms, struct gsm48_sysinfo *s) "HSN = %d hseq (%d): %s\n", s->chan_nr, s->tsc, s->maio, s->hsn, s->hopp_len, - hexdump((unsigned char *) s->hopping, s->hopp_len * 2)); + osmo_hexdump((unsigned char *) s->hopping, s->hopp_len * 2)); return l1ctl_tx_dm_est_req_h1(ms, s->maio, s->hsn, s->hopping, s->hopp_len, s->chan_nr, s->tsc, diff --git a/src/host/layer23/src/mobile/vty_interface.c b/src/host/layer23/src/mobile/vty_interface.c index debe36e..80a756c 100644 --- a/src/host/layer23/src/mobile/vty_interface.c +++ b/src/host/layer23/src/mobile/vty_interface.c @@ -1170,11 +1170,11 @@ static void config_write_ms(struct vty *vty, struct osmocom_ms *ms) vty_out(vty, " imsi %s%s", set->test_imsi, VTY_NEWLINE); switch (set->test_ki_type) { case GSM_SIM_KEY_XOR: - vty_out(vty, " ki xor %s%s", hexdump(set->test_ki, 12), + vty_out(vty, " ki xor %s%s", osmo_hexdump(set->test_ki, 12), VTY_NEWLINE); break; case GSM_SIM_KEY_COMP128: - vty_out(vty, " ki comp128 %s%s", hexdump(set->test_ki, 16), + vty_out(vty, " ki comp128 %s%s", osmo_hexdump(set->test_ki, 16), VTY_NEWLINE); break; } diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index ab977c1..7f8d3ac 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -447,7 +447,7 @@ int read_file(const char *filename) return 0; } -static void osmocon_hexdump(const uint8_t *data, unsigned int len) +static void osmocon_osmo_hexdump(const uint8_t *data, unsigned int len) { int n; @@ -754,7 +754,7 @@ static void hdlc_send_to_phone(uint8_t dlci, uint8_t *data, int len) if(dnload.dump_tx) { printf("hdlc_send(dlci=%u): ", dlci); - osmocon_hexdump(data, len); + osmocon_osmo_hexdump(data, len); } if (len > 512) { @@ -792,7 +792,7 @@ static void hdlc_tool_cb(uint8_t dlci, struct msgb *msg) if(dnload.dump_rx) { printf("hdlc_recv(dlci=%u): ", dlci); - osmocon_hexdump(msg->data, msg->len); + osmocon_osmo_hexdump(msg->data, msg->len); } if(srv) { @@ -832,7 +832,7 @@ static int handle_buffer(int buf_used_len) if (!dnload.expect_hdlc) { printf("got %i bytes from modem, ", nbytes); printf("data looks like: "); - osmocon_hexdump(bufptr, nbytes); + osmocon_osmo_hexdump(bufptr, nbytes); } else { for (i = 0; i < nbytes; ++i) if (sercomm_drv_rx_char(bufptr[i]) == 0) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 1471a2e..5848e56 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -146,7 +146,7 @@ static int version(const char *name) exit(2); } -static void osmoload_hexdump(const uint8_t *data, unsigned int len) +static void osmoload_osmo_hexdump(const uint8_t *data, unsigned int len) { const uint8_t *bufptr = data; const uint8_t const *endptr = bufptr + len; @@ -190,7 +190,7 @@ loader_send_request(struct msgb *msg) { if(osmoload.print_requests) { printf("Sending %d bytes:\n", msg->len); - osmoload_hexdump(msg->data, msg->len); + osmoload_osmo_hexdump(msg->data, msg->len); } rc = write(connection.fd, &len, sizeof(len)); @@ -277,7 +277,7 @@ static void loader_handle_reply(struct msgb *msg) { if(osmoload.print_replies) { printf("Received %d bytes:\n", msg->len); - osmoload_hexdump(msg->data, msg->len); + osmoload_osmo_hexdump(msg->data, msg->len); } uint8_t cmd = msgb_get_u8(msg); @@ -338,7 +338,7 @@ loader_handle_reply(struct msgb *msg) { break; default: printf("Received unknown reply %d:\n", cmd); - osmoload_hexdump(msg->data, msg->len); + osmoload_osmo_hexdump(msg->data, msg->len); osmoload.quit = 1; return; } @@ -364,7 +364,7 @@ loader_handle_reply(struct msgb *msg) { break; case LOADER_MEM_READ: printf("Received memory dump of %d bytes at 0x%x:\n", length, address); - osmoload_hexdump(data, length); + osmoload_osmo_hexdump(data, length); break; case LOADER_MEM_WRITE: printf("Confirmed memory write of %d bytes at 0x%x.\n", length, address); -- 1.7.2.3 From pablo at gnumonks.org Sun May 15 13:14:26 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sun, 15 May 2011 15:14:26 +0200 Subject: [PATCH 6/6] src: use namespace prefix osmo_* for crc16 functions In-Reply-To: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> Message-ID: <1305465266-18081-7-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Summary of changes: s/crc16_table/osmo_crc16_table/g s/crc16/osmo_crc16/g s/crc16_byte/osmo_crc16_byte/g --- src/host/osmocon/osmoload.c | 8 ++++---- src/target/firmware/apps/loader/main.c | 6 +++--- src/target/firmware/apps/loader_mtk/main.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 5848e56..8a0b21c 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -575,7 +575,7 @@ loader_start_memput(uint8_t length, uint32_t address, void *data) { struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); msgb_put_u8(msg, LOADER_MEM_WRITE); msgb_put_u8(msg, length); - msgb_put_u16(msg, crc16(0, data, length)); + msgb_put_u16(msg, osmo_crc16(0, data, length)); msgb_put_u32(msg, address); memcpy(msgb_put(msg, length), data, length); loader_send_request(msg); @@ -603,7 +603,7 @@ loader_do_memdump(uint16_t crc, void *data, size_t length) { int rc; if(data && length) { - osmoload.memcrc = crc16(0, data, length); + osmoload.memcrc = osmo_crc16(0, data, length); if(osmoload.memcrc != crc) { osmoload.memoff -= osmoload.memreq; printf("\nbad crc %4.4x (not %4.4x) at offset 0x%8.8x", crc, osmoload.memcrc, osmoload.memoff); @@ -665,7 +665,7 @@ loader_do_memload() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); @@ -705,7 +705,7 @@ loader_do_fprogram() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index a948934..2ff6f9c 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -253,7 +253,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -274,7 +274,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -392,7 +392,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 899d765..9bfaa7e 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -194,7 +194,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -215,7 +215,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -333,7 +333,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); -- 1.7.2.3 From laforge at gnumonks.org Sun May 22 10:17:11 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 May 2011 12:17:11 +0200 Subject: [PATCH 0/6] osmocom-bb: get in sync with libosmocore namespace changes In-Reply-To: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> References: <1305465266-18081-1-git-send-email-pablo@gnumonks.org> Message-ID: <20110522101711.GK4243@prithivi.gnumonks.org> Hi Pablo, On Sun, May 15, 2011 at 03:14:20PM +0200, pablo at gnumonks.org wrote: > This patchset gets osmocom-bb in sync with the namespace fixes for > libosmocore. sorry for the delays, I'm finally merging it right now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gianni at scaramanga.co.uk Sun May 15 15:50:40 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Sun, 15 May 2011 16:50:40 +0100 Subject: [PATCH,v2] SMS decode Message-ID: <1305474640.5089.4.camel@deckard> This is a folowup to previous patch implementing SMS decoding. I have removed the 7bit decoding functions to use those in libosmocore. This time I have also tried to send CP-ACK in response to the CP-DATA containing the SMS. But this seems to break the entire state machine, not sure what I'm doing wrong here. I just built the packet and used gsm48_rr_downmsg() to send it. Maybe I just need to learn more about the lower layers. A BTS or a GSM tester would be really handy I guess... Gianni diff --git a/src/host/layer23/include/osmocom/bb/mobile/gsm48_sms.h b/src/host/layer23/include/osmocom/bb/mobile/gsm48_sms.h new file mode 100644 index 0000000..99911ad --- /dev/null +++ b/src/host/layer23/include/osmocom/bb/mobile/gsm48_sms.h @@ -0,0 +1,7 @@ +#ifndef _GSM48_SMS_H +#define _GSM48_SMS_H + +int gsm48_rcv_sms(struct osmocom_ms *ms, struct msgb *msg); + +#endif /* _GSM48_SMS_H */ + diff --git a/src/host/layer23/src/mobile/Makefile.am b/src/host/layer23/src/mobile/Makefile.am index fb0423e..60e8d23 100644 --- a/src/host/layer23/src/mobile/Makefile.am +++ b/src/host/layer23/src/mobile/Makefile.am @@ -4,7 +4,7 @@ LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOVTY_LIBS) $(LIBOSMOG noinst_LIBRARIES = libmobile.a libmobile_a_SOURCES = gsm322.c gsm48_cc.c gsm48_mm.c gsm48_rr.c \ - mnccms.c settings.c subscriber.c support.c \ + gsm48_sms.c mnccms.c settings.c subscriber.c support.c \ transaction.c vty_interface.c bin_PROGRAMS = mobile diff --git a/src/host/layer23/src/mobile/gsm48_mm.c b/src/host/layer23/src/mobile/gsm48_mm.c index bf5bbc2..2155a71 100644 --- a/src/host/layer23/src/mobile/gsm48_mm.c +++ b/src/host/layer23/src/mobile/gsm48_mm.c @@ -36,6 +36,7 @@ #include #include #include +#include #include extern void *l23_ctx; @@ -737,10 +738,10 @@ int gsm48_mmxx_dequeue(struct osmocom_ms *ms) case GSM48_MMSS_CLASS: gsm48_rcv_ss(ms, msg); break; +#endif case GSM48_MMSMS_CLASS: gsm48_rcv_sms(ms, msg); break; -#endif } msgb_free(msg); work = 1; /* work done */ @@ -3788,11 +3789,11 @@ static int gsm48_mm_data_ind(struct osmocom_ms *ms, struct msgb *msg) rr_prim = GSM48_MMSS_DATA_IND; rr_est = GSM48_MMSS_EST_IND; break; +#endif case GSM48_PDISC_SMS: rr_prim = GSM48_MMSMS_DATA_IND; rr_est = GSM48_MMSMS_EST_IND; break; -#endif } if (rr_prim != -1) { uint8_t transaction_id = ((gh->proto_discr & 0xf0) ^ 0x80) >> 4; @@ -3847,9 +3848,10 @@ static int gsm48_mm_data_ind(struct osmocom_ms *ms, struct msgb *msg) case GSM48_PDISC_NC_SS: return gsm48_rcv_ss(ms, msg); +#endif case GSM48_PDISC_SMS: + LOGP(DMM, LOGL_NOTICE, "SMS PDISC = 0x%.2x\n", GSM48_PDISC_SMS); return gsm48_rcv_sms(ms, msg); -#endif default: LOGP(DMM, LOGL_NOTICE, "Protocol type 0x%02x unsupported.\n", diff --git a/src/host/layer23/src/mobile/gsm48_sms.c b/src/host/layer23/src/mobile/gsm48_sms.c new file mode 100644 index 0000000..5337b1e --- /dev/null +++ b/src/host/layer23/src/mobile/gsm48_sms.c @@ -0,0 +1,355 @@ +/* + * (C) 2010 by Andreas Eversberg + * (C) 2011 by Gianni Tedesco + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +/* GSM 04.11 Table 8.1 */ +#define CP_DATA 1 +#define CP_ACK 4 +#define CP_ERROR 16 + +#define CP_CAUSE_INVALID_MANDATORY_INFO 96 +#define CP_CAUSE_MSG_TYPE_NOT_IMPLEMENTED 97 +#define CP_CAUSE_INFO_ELEMENT_NOT_IMPLEMENTED 97 +#define CP_CAUSE_PROTOCOL_ERROR 111 + +#define RP_DATA 1 +#define RP_ACK 3 +#define RP_ERROR 5 + +#define TP_MTI_MASK 3 +#define SMS_DELIVER 0 +#define SMS_SUBMIT_REPORT 1 +#define SMS_STATUS_REPORT 2 + +#define TP_RP 0x80 +#define TP_UDHI 0x40 +#define TP_SRI 0x20 +#define TP_MMS 0x04 + +static uint8_t hi_nibble(uint8_t byte) +{ + return byte >> 4; +} + +static uint8_t lo_nibble(uint8_t byte) +{ + return byte & 0xf; +} + +static int parse_address(struct msgb *msg, int rp, const char *name) +{ + uint8_t len, type; + + if ( !msg->len ) + return -EPROTO; + + len = msgb_get_u8(msg); + if ( !len ) + return 0; + + type = msgb_get_u8(msg); + + if ( rp ) { + /* for RP address, len is in bytes including type field */ + len = len - 1; + }else{ + /* TP address is in BCD digits, not including type field */ + len = len / 2; + } + + if ( msg->len < len ) + return -EPROTO; + + LOGP(DMM, LOGL_NOTICE, "%s: type=0x%.2x %s\n", + name, type, hexdump(msg->data, len)); + + msgb_pull(msg, len); + return 0; +} + +static int parse_timestamp(struct msgb *msg, const char *name) +{ + if ( msg->len < 7 ) + return -EPROTO; + LOGP(DMM, LOGL_NOTICE, + "%s: 20%1x%1x-%1x%1x-%1x%1x %1x%1x:%1x%1x:%1x%1x\n", + name, + lo_nibble(msg->data[0]), + hi_nibble(msg->data[0]), + lo_nibble(msg->data[1]), + hi_nibble(msg->data[1]), + lo_nibble(msg->data[2]), + hi_nibble(msg->data[2]), + lo_nibble(msg->data[3]), + hi_nibble(msg->data[3]), + lo_nibble(msg->data[4]), + hi_nibble(msg->data[4]), + lo_nibble(msg->data[5]), + hi_nibble(msg->data[5])); + msgb_pull(msg, 7); + return 0; +} + +static int sms_7bit(const uint8_t *in, size_t octets, size_t chars) +{ + char out[chars + 1]; + + if ( (chars * 7 + 6) / 8 > octets ) { + chars = (octets * 8) / 7; + octets = (chars * 7 + 6) / 8; + } + + gsm_7bit_decode(out, in, octets); + LOGP(DMM, LOGL_NOTICE, "SMS-MSG: %s\n", out); + return 0; +} + +static int sms_deliver(struct osmocom_ms *ms, struct msgb *msg, uint8_t b) +{ + uint8_t tp_pid, tp_dcs, tp_udlen; + int rc; + + if ( !(b & TP_MMS) ) + LOGP(DMM, LOGL_NOTICE, "SMS-DELIVER: More messages to send.\n"); + + rc = parse_address(msg, 0, "TP-Originating"); + if ( rc ) + return -EPROTO; + + if ( msg->len < 2 ) + return -EPROTO; + + tp_pid = msgb_get_u8(msg); + tp_dcs = msgb_get_u8(msg); + LOGP(DMM, LOGL_NOTICE, "TP-PID: 0x%.2x\n", tp_pid); + LOGP(DMM, LOGL_NOTICE, "TP-DCS: 0x%.2x\n", tp_dcs); + + rc = parse_timestamp(msg, "TP-Service-Center-Time-Stamp"); + if ( rc ) + return -EPROTO; + + if ( !msg->len ) + return -EPROTO; + tp_udlen = msgb_get_u8(msg); + + /* TODO: user-data-header? */ + + /* check for unknown data coding scheme */ + switch(tp_dcs) { + case 0: + return sms_7bit(msg->data, msg->len, tp_udlen); + default: + return -EPROTO; + } + + return 0; +} + +static int sms_tpdu_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t tp_mti; + + if ( !msg->len ) + return 0; + tp_mti = msgb_get_u8(msg); + + switch(tp_mti & TP_MTI_MASK) { + case SMS_DELIVER: + return sms_deliver(ms, msg, tp_mti); + case SMS_SUBMIT_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-SUBMIT-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + case SMS_STATUS_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-STATUS-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + default: + LOGP(DMM, LOGL_NOTICE, "Reserved MTI: 0x%.2x\n", + tp_mti); + return -EPROTO; + } + + return 0; +} + +static int rp_data_decode(struct osmocom_ms *ms, struct msgb *msg, uint8_t ref) +{ + static const char * const str[2] = {"RP-Origination", "RP-Destination"}; + unsigned int i; + uint8_t tpdu_len; + + LOGP(DMM, LOGL_NOTICE, "Received RP-DATA: ref %d\n", ref); + + for(i = 0; i < 2; i++) { + int rc; + + rc = parse_address(msg, 1, str[i]); + if ( rc ) + return -EPROTO; + } + + if ( !msg->len ) + return -EPROTO; + tpdu_len = msgb_get_u8(msg); + if ( tpdu_len < msg->len ) + return -EPROTO; + if ( tpdu_len < msg->len ) { + LOGP(DMM, LOGL_NOTICE, "RP-DATA: %u trailing bytes: %s\n", + msg->len - tpdu_len, + hexdump(msg->data + tpdu_len, msg->len - tpdu_len)); + msg->len = tpdu_len; + } + + /* TODO: pass in reference, and src/dst addresses */ + return sms_tpdu_decode(ms, msg); +} + +/* TODO: whatever happens here we need to send RP-ACK or RP-ERROR */ +static int rp_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t rp_mt, rp_ref; + + if ( msg->len < 2 ) + return -EPROTO; + + rp_mt = msgb_get_u8(msg); + rp_ref = msgb_get_u8(msg); + + switch(rp_mt) { + case RP_DATA: + return rp_data_decode(ms, msg, rp_ref); + case RP_ACK: + LOGP(DMM, LOGL_NOTICE, "Received RP-ACK: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + case RP_ERROR: + LOGP(DMM, LOGL_NOTICE, "Received RP-ERROR: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + default: + LOGP(DMM, LOGL_NOTICE, "Bad RP Message-type: 0x%.2x\n", rp_mt); + return -ENOTSUP; + } + + return 0; +} + +static int cp_tx_error(struct osmocom_ms *ms, uint8_t tid, uint8_t cause) +{ + struct gsm48_hdr *gh; + struct msgb *msg; + + msg = gsm48_l3_msgb_alloc(); + if ( NULL == msg ) + return -ENOMEM; + + gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); + gh->proto_discr = tid | GSM48_PDISC_SMS; + gh->msg_type = CP_ERROR; + msgb_put_u8(msg, cause); + return gsm48_rr_downmsg(ms, msg); +} + +static int cp_tx_ack(struct osmocom_ms *ms, uint8_t tid) +{ + struct gsm48_hdr *gh; + struct msgb *msg; + + msg = gsm48_l3_msgb_alloc(); + if ( NULL == msg ) + return -ENOMEM; + + gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); + gh->proto_discr = tid | GSM48_PDISC_SMS; + gh->msg_type = CP_ACK; + return gsm48_rr_downmsg(ms, msg); +} + +static int cp_data(struct osmocom_ms *ms, uint8_t tid, struct msgb *msg) +{ + uint8_t len; + + if ( !msg->len ) { + return cp_tx_error(ms, tid, CP_CAUSE_PROTOCOL_ERROR); + } + + len = msgb_get_u8(msg); + if ( len != msg->len ) { + LOGP(DMM, LOGL_NOTICE, "CP-DATA: size mismatch " + "%u != %u bytes\n", len, msg->len); + }else{ + LOGP(DMM, LOGL_NOTICE, "CP-DATA: %u bytes\n", len); + } + + rp_decode(ms, msg); + return cp_tx_ack(ms, tid); +} + +int gsm48_rcv_sms(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t cp_type, tid; + int rc; + + LOGP(DMM, LOGL_NOTICE, "Received SMS: %s\n", + hexdump(msg->data, msg->len)); + + tid = msgb_get_u8(msg) & 0xf0; + if (!msg->len) { + rc = cp_tx_error(ms, tid, CP_CAUSE_PROTOCOL_ERROR); + goto out; + } + + cp_type = msgb_get_u8(msg); + + switch(cp_type) { + case CP_DATA: + rc = cp_data(ms, tid, msg); + break; + default: + LOGP(DMM, LOGL_NOTICE, "Unknown SMS type: 0x%.2x\n", cp_type); + rc = cp_tx_error(ms, tid, CP_CAUSE_MSG_TYPE_NOT_IMPLEMENTED); + break; + } + +out: + msgb_free(msg); + return rc; +} From wpatan at gmail.com Mon May 16 00:52:04 2011 From: wpatan at gmail.com (wpatan) Date: Sun, 15 May 2011 17:52:04 -0700 (PDT) Subject: [PATCH,v2] SMS decode In-Reply-To: <1305474640.5089.4.camel@deckard> References: <1305474640.5089.4.camel@deckard> Message-ID: <1305507124684-2945936.post@n3.nabble.com> Thanks Gianni, I was able to test your previous patch... but I had to modify some header links because I'm using sylvain/test branch.. I'll try this new patch tonight. Cheers! Wpatan -- View this message in context: http://baseband-devel.722152.n3.nabble.com/PATCH-v2-SMS-decode-tp2945493p2945936.html Sent from the baseband-devel mailing list archive at Nabble.com. From info at sharonsoft.com Mon May 16 17:30:38 2011 From: info at sharonsoft.com (Sun Ich) Date: Mon, 16 May 2011 10:30:38 -0700 (PDT) Subject: Osmocom building in Ubuntu Error Message-ID: <969164.78078.qm@web1106.biz.mail.sk1.yahoo.com> Hi I try to compile osmocom in Ubuntu, I have gcc 4.4.3 and I installed binutils 2.20 for ARM successfully and I have arm-elf-* binaries in PATH directory when I run make in src folder of osmocom, I get error: unknown instruction "ror xor" something something.... What's problem, do I missing something? Thanks From klaus.rechert at rz.uni-freiburg.de Mon May 16 20:46:05 2011 From: klaus.rechert at rz.uni-freiburg.de (Klaus Rechert) Date: Mon, 16 May 2011 22:46:05 +0200 Subject: MacOSX build Message-ID: <4DD18D0D.80307@rz.uni-freiburg.de> Hi, some quick notes on the MacOSX build. Current git builds fine using the perbuilt GNUARM MacOS toolchain except that GCC 3.3 does not support the option -Wextra. There are also some issues building mtk firmware but this seems to be a more general issue. Cheers Klaus diff --git a/src/target/firmware/Makefile.inc b/src/target/firmware/Makefile.inc index 1f54031..c8f4323 100644 --- a/src/target/firmware/Makefile.inc +++ b/src/target/firmware/Makefile.inc @@ -12,7 +12,7 @@ OBJCOPY=objcopy DEBUGF=dwarf-2 CFLAGS=-mcpu=arm7tdmi $(INCLUDES) -CFLAGS += -Wall -Wextra -Wcast-align -Wimplicit -Wunused +CFLAGS += -Wall -Wcast-align -Wimplicit -Wunused CFLAGS += -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wnested-externs CFLAGS += -Wbad-function-cast -Wsign-compare -Waggregate-return CFLAGS += -Os -ffunction-sections From klaus.rechert at rz.uni-freiburg.de Mon May 16 20:58:36 2011 From: klaus.rechert at rz.uni-freiburg.de (Klaus Rechert) Date: Mon, 16 May 2011 22:58:36 +0200 Subject: MacOSX build In-Reply-To: <4DD18D0D.80307@rz.uni-freiburg.de> References: <4DD18D0D.80307@rz.uni-freiburg.de> Message-ID: <4DD18FFC.6050400@rz.uni-freiburg.de> > some quick notes on the MacOSX build. Current git builds fine using > the perbuilt GNUARM MacOS toolchain except that GCC 3.3 does not > support the option -Wextra. -Wextra was formerly known as -w and is still supported (cf. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) Maybe this can be changed to support older toolchains. However, it is a minor issue. Cheers Klaus diff --git a/src/target/firmware/Makefile.inc b/src/target/firmware/Makefile.inc index 1f54031..3783355 100644 --- a/src/target/firmware/Makefile.inc +++ b/src/target/firmware/Makefile.inc @@ -12,7 +12,7 @@ OBJCOPY=objcopy DEBUGF=dwarf-2 CFLAGS=-mcpu=arm7tdmi $(INCLUDES) -CFLAGS += -Wall -Wextra -Wcast-align -Wimplicit -Wunused +CFLAGS += -Wall -w -Wcast-align -Wimplicit -Wunused CFLAGS += -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wnested-externs CFLAGS += -Wbad-function-cast -Wsign-compare -Waggregate-return CFLAGS += -Os -ffunction-sections From ichgeh at l--putt.de Mon May 16 22:09:13 2011 From: ichgeh at l--putt.de (l--putt) Date: Tue, 17 May 2011 00:09:13 +0200 Subject: Power management Message-ID: <4DD1A089.1070704@l--putt.de> Hi list! Some time ago Harald suggested to create a complete phone, at least with minimal features. Since this hasn't been covered yet and we will have to rewrite some parts during RTOS porting anyway, I think we should consider some kind of power management: Saving power Having everything on and at maximum clock drains the battery _fast_! With the ULPD, we actually have the appropriate solution build into the Calypso. I guess other chipsets have something similar. It is neat to get the timing and power sequence right. But since the TDMA timing is affected, Layer 1 must be aware of those clock/power changes or at least tolerate to be turned on and off. Does anybody right away have ideas how to approach this? Charger The C155 has a dedicated chip which you probably just have to turn on. On the C123, it's a bit more complex but the algorithms don't seem to be too complex. Has anybody tried this already? State-of-Charge For the usual concepts on batteryuniversity.com, a random book from the university lib, and some papers, we would need some means to measure the discharge current. No Compal phone provides this since the voltage regulators are connected directly to the battery. The gta02 avoids this with a dedicated Coulomb-counting chip. The gta01 doesn't care!? Maybe the battery voltage and temperature is sufficient for reasonably correct estimates. If not, we could try to model the current. However, this requires some kind of central power management that knows activated devices, their clocks, etc. I would volunteer for the latter and C155-charging. However, I lack a C123 for tests and don't want to be responsible for exploding phones ;) Integration of the ULPD is a bit more GSM-related. Might turn out to be interesting... Cheers, Stefan From spaar at mirider.augusta.de Tue May 17 07:29:17 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 17 May 2011 07:29:17 CEST Subject: Power management Message-ID: <4dd2863d.mirider@mirider.augusta.de> Hello Stefan, On Tue, 17 May 2011 00:09:13 +0200, "l--putt" wrote: > > Saving power > Having everything on and at maximum clock drains the battery _fast_! > With the ULPD, we actually have the appropriate solution build into the > Calypso. I guess other chipsets have something similar. > It is neat to get the timing and power sequence right. But since the > TDMA timing is affected, Layer 1 must be aware of those clock/power > changes or at least tolerate to be turned on and off. Does anybody right > away have ideas how to approach this? A few notes, I don't remember the details: The basic idea is to only receive in idle mode when its necessary. This means listening only for the paging group of the IMSI and doing the neighbour cell measurements. During the other time the processor can be stopped. There are different levels to which extend the clock is stopped, for saving the most power only the 32 kHz crystal remains active. However this requires some calibration, otherwise the TDMA frames could be missed after sleeping. Most of this calibration can be done with the help of the hardware, its always done before switching to 32 kHz. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 775725965 at qq.com Tue May 17 11:15:36 2011 From: 775725965 at qq.com (=?gbk?B?wvPM78rYzfs=?=) Date: Tue, 17 May 2011 19:15:36 +0800 Subject: hi all Message-ID: do you know the mtk chip MT6217 it is usb interface chip we can use to make a GSM network the mt6217 with pc -------------- next part -------------- An HTML attachment was scrubbed... URL: From ichgeh at l--putt.de Wed May 18 21:39:49 2011 From: ichgeh at l--putt.de (l--putt) Date: Wed, 18 May 2011 23:39:49 +0200 Subject: Nuttx for Calypso Message-ID: <4DD43CA5.70803@l--putt.de> Hi list! As you can see from the patch, I made some progress with a port of Nuttx to the Calypso platform. The UART doesn't work yet. The few possible tests with just the backlight suggest that the IRQ is working. More work required but I'd like to avoid doing the work twice. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: nuttx-calypso.patch.gz Type: application/x-gzip Size: 39501 bytes Desc: not available URL: From laforge at gnumonks.org Thu May 19 07:34:19 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 19 May 2011 09:34:19 +0200 Subject: Nuttx for Calypso In-Reply-To: <4DD43CA5.70803@l--putt.de> References: <4DD43CA5.70803@l--putt.de> Message-ID: <20110519073419.GF2974@prithivi.gnumonks.org> Hi Stefan, On Wed, May 18, 2011 at 11:39:49PM +0200, l--putt wrote: > As you can see from the patch, I made some progress with a port of > Nuttx to the Calypso platform. The UART doesn't work yet. The few > possible tests with just the backlight suggest that the IRQ is > working. More work required but I'd like to avoid doing the work > twice. I've created a nuttx-bb.git repository on git.osmocom.org which right now only contains a git svn clone of the official Nuttx repository (as git branch "trunk"). I'd suggest you send me your ssh key and I will give you commit access to that repoisotory. The same applies for anyone who wants to work on the core calypso port. btw, from quickly reviewing your patch: I don't think you need to import the full dsp_api header files... rather the rule should be to only import those header files and code portions which are essential for making the calypso base port work (ignoring anything gsm/l1 related for the time being). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From drasko.draskovic at gmail.com Thu May 19 10:29:48 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Thu, 19 May 2011 12:29:48 +0200 Subject: Nuttx for Calypso In-Reply-To: <20110519073419.GF2974@prithivi.gnumonks.org> References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> Message-ID: On Thu, May 19, 2011 at 9:34 AM, Harald Welte wrote: > I've created a nuttx-bb.git repository on git.osmocom.org which right > now only contains a git svn clone of the official Nuttx repository (as > git branch "trunk"). I have hard time checking it out : git clone git://git.osmocom.org/nuttx-bb.git Initialized empty Git repository in /home/ddraskovic/sandbox/nuttx/nuttx-bb/.git/ remote: Counting objects: 53851, done. remote: Compressing objects: 100% (9244/9244), done. remote: Total 53851 (delta 44307), reused 53851 (delta 44307) Receiving objects: 100% (53851/53851), 12.07 MiB | 451 KiB/s, done. Resolving deltas: 100% (44307/44307), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Any ideas ? BR, Drasko From wolfram at the-dreams.de Thu May 19 10:45:10 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Thu, 19 May 2011 12:45:10 +0200 Subject: Nuttx for Calypso In-Reply-To: References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> Message-ID: <4DD4F4B6.7050102@the-dreams.de> >> I've created a nuttx-bb.git repository on git.osmocom.org which right >> now only contains a git svn clone of the official Nuttx repository (as >> git branch "trunk"). > > I have hard time checking it out : As Harald said, there is no master, you have to checkout trunk. Either during clone or afterwards in your directory. From drasko.draskovic at gmail.com Thu May 19 13:21:24 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Thu, 19 May 2011 15:21:24 +0200 Subject: Nuttx for Calypso In-Reply-To: <4DD4F4B6.7050102@the-dreams.de> References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> <4DD4F4B6.7050102@the-dreams.de> Message-ID: On Thu, May 19, 2011 at 12:45 PM, Wolfram Sang wrote: >>> I've created a nuttx-bb.git repository on git.osmocom.org which right >>> now only contains a git svn clone of the official Nuttx repository (as >>> git branch "trunk"). >> >> I have hard time checking it out : > > As Harald said, there is no master, you have to checkout trunk. Either > during clone or afterwards in your directory. How to do this ? BR, Drasko From squalyl at gmail.com Thu May 19 13:52:56 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Thu, 19 May 2011 15:52:56 +0200 Subject: Nuttx for Calypso In-Reply-To: References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> <4DD4F4B6.7050102@the-dreams.de> Message-ID: go where you typed git clone, then type: git checkout trunk :-) Sebastien On Thu, May 19, 2011 at 3:21 PM, Drasko DRASKOVIC < drasko.draskovic at gmail.com> wrote: > On Thu, May 19, 2011 at 12:45 PM, Wolfram Sang > wrote: > >>> I've created a nuttx-bb.git repository on git.osmocom.org which right > >>> now only contains a git svn clone of the official Nuttx repository (as > >>> git branch "trunk"). > >> > >> I have hard time checking it out : > > > > As Harald said, there is no master, you have to checkout trunk. Either > > during clone or afterwards in your directory. > > How to do this ? > > BR, > Drasko > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drasko.draskovic at gmail.com Thu May 19 14:01:17 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Thu, 19 May 2011 16:01:17 +0200 Subject: Nuttx for Calypso In-Reply-To: References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> <4DD4F4B6.7050102@the-dreams.de> Message-ID: On Thu, May 19, 2011 at 3:52 PM, S?bastien Lorquet wrote: > go where you typed git clone, then type: > > git checkout trunk :-) This does not work... Or I am missing something. Can somebody please post working set of git commands to checkout OsmocomBB NuttX port ? BR, Drasko From staszek.wasiutynski at gmail.com Thu May 19 14:06:03 2011 From: staszek.wasiutynski at gmail.com (=?ISO-8859-2?Q?Stanis=B3aw_Wasiuty=F1ski?=) Date: Thu, 19 May 2011 16:06:03 +0200 Subject: Nuttx for Calypso In-Reply-To: References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> <4DD4F4B6.7050102@the-dreams.de> Message-ID: git clone git://git.osmocom.org/nuttx-bb.git cd nuttx-bb git checkout -b trunk origin/trunk This will create a local branch and allow you to work on that. On Thu, May 19, 2011 at 4:01 PM, Drasko DRASKOVIC wrote: > On Thu, May 19, 2011 at 3:52 PM, S?bastien Lorquet wrote: >> go where you typed git clone, then type: >> >> git checkout trunk :-) > > This does not work... Or I am missing something. > > Can somebody please post working set of git commands to checkout > OsmocomBB NuttX port ? > > BR, > Drasko > > -- Pozdrawiam, Stanis?aw Wasiuty?ski From squalyl at gmail.com Thu May 19 15:13:34 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Thu, 19 May 2011 17:13:34 +0200 Subject: Nuttx for Calypso In-Reply-To: References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> <4DD4F4B6.7050102@the-dreams.de> Message-ID: Sorry Drasko, I don't know why my short version worked on msysgit! Sebastien 2011/5/19 Stanis?aw Wasiuty?ski > git clone git://git.osmocom.org/nuttx-bb.git > cd nuttx-bb > git checkout -b trunk origin/trunk > > This will create a local branch and allow you to work on that. > > On Thu, May 19, 2011 at 4:01 PM, Drasko DRASKOVIC > wrote: > > On Thu, May 19, 2011 at 3:52 PM, S?bastien Lorquet > wrote: > >> go where you typed git clone, then type: > >> > >> git checkout trunk :-) > > > > This does not work... Or I am missing something. > > > > Can somebody please post working set of git commands to checkout > > OsmocomBB NuttX port ? > > > > BR, > > Drasko > > > > > > > > -- > Pozdrawiam, > Stanis?aw Wasiuty?ski > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu May 19 17:31:44 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 19 May 2011 19:31:44 +0200 Subject: Nuttx for Calypso In-Reply-To: References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> Message-ID: <20110519173144.GE3057@prithivi.gnumonks.org> On Thu, May 19, 2011 at 12:29:48PM +0200, Drasko DRASKOVIC wrote: > On Thu, May 19, 2011 at 9:34 AM, Harald Welte wrote: > > > I've created a nuttx-bb.git repository on git.osmocom.org which right > > now only contains a git svn clone of the official Nuttx repository (as > > git branch "trunk"). > > I have hard time checking it out : this was due to the missing 'master' branch in the repository. I've fixed this now (master is just a copy of trunk), and it is working at leaset here. Over time, master should be where our code is, and 'trunk' is the upstream repository. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From drasko.draskovic at gmail.com Thu May 19 21:05:51 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Thu, 19 May 2011 23:05:51 +0200 Subject: Nuttx for Calypso In-Reply-To: <20110519173144.GE3057@prithivi.gnumonks.org> References: <4DD43CA5.70803@l--putt.de> <20110519073419.GF2974@prithivi.gnumonks.org> <20110519173144.GE3057@prithivi.gnumonks.org> Message-ID: On Thu, May 19, 2011 at 7:31 PM, Harald Welte wrote: > this was due to the missing 'master' branch in the repository. ?I've > fixed this now (master is just a copy of trunk), and it is working at > leaset here. Thanks Harald, simple git clone works now. Best regards, Drasko From 246tnt at gmail.com Mon May 23 14:12:02 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 23 May 2011 16:12:02 +0200 Subject: Nuttx for Calypso In-Reply-To: <4DD43CA5.70803@l--putt.de> References: <4DD43CA5.70803@l--putt.de> Message-ID: Hi, > As you can see from the patch, I made some progress with a port of Nuttx to > the Calypso platform. The UART doesn't work yet. The few possible tests with > just the backlight suggest that the IRQ is working. More work required but > I'd like to avoid doing the work twice. I've just add a quick look at the patch (really, just 10 min) and I have a few comments: - I think it'd be better to progressively add support. I see for example you copied a bunch of the header over (including things that definitely cleaning like l1_environment.h and that one is probably not gonna be in the nutt-x repo anyway) - Make it a patch series adding things one by one so we can see a progress / logical path when reviewing (like 1: base structure, 2: statrup files 3: interrupts ....) Also (unrelated to the patch), somethings that I think should be discussed/addressed soon are: - How we will handle the boards in nuttx (including variants like US/EU version of the same phone) - How we will handle the memory zones (SRAM / SDRAM / Flash / XIP from flash (or just .rodata ?)) - How we will handle our different ram config (boot from ram / flash), can we use the loader to load part of the SDRAM if we don't fit in SRAM completely ? - Memory allocator (handling zones ...). I think that'd be something very useful. Currently we can only allocate msgb and that's a little limiting. (nuttx may have mechanism in place already for those, I'm not sure yet) Just my 10 cents. Cheers, Sylvain From spudarnia at yahoo.com Mon May 23 21:14:52 2011 From: spudarnia at yahoo.com (Gregory Nutt) Date: Mon, 23 May 2011 14:14:52 -0700 (PDT) Subject: Nuttx for Calypso In-Reply-To: References: Message-ID: <82542.44346.qm@web31809.mail.mud.yahoo.com> Hi, Let me volunteer suggestions to at some of your questions. > Also (unrelated to the patch), somethings that I think should be > discussed/addressed soon are: >? > - How we will handle the boards in nuttx (including variants like > US/EU version of the same phone) Nuttx is designed to support a hiearchical configuration: ?processor family, chips in the family, boards that host the chips, and board software configurations. NuttX is configured with .config file. ?In that file you specify the family (ARM), the chip (Calypso), and the board (also Calypso now?). ?The family corresponds to a directory under arch/ (arch/arm) and the chip corresponds to sub-directories under arch/arm/src and arch/arm/include (arch/arm/src/calypso and arch/arm/include/calypso). * arch/arm/include holds general ARM header files * arch/arm/include/calypso holds calypso specific header files * arch/arm/src/calypso holds calypso specific source files Boards are represented by directories under configs/. ?Right now, I think there is only a configs/compal_e99. * configs/compal_e99/include holds Compal E99 specific header files * configs/compal_e99/src holds Compal E99 specific header files Other directories under configs/compal_e99 can hold different software configurations for the same board. ?For example, configs/compal_e99/ostest holds the make logic for the OS test; configs/compal_e99/nsh would hold the NuttShell (NSH) make configuration files, etc. ?The .config file, for example, is on of the software configuration files in those directories (it is call defconfig before it is copied to the top-level directory as .config). You can see these settings in the .config/defconfig file: CONFIG_ARCH=arm >CONFIG_ARCH_ARM=y >CONFIG_ARCH_ARM7TDMI=y >CONFIG_ARCH_CHIP=calypso >CONFIG_ARCH_CHIP_CALYPSO=y >CONFIG_ARCH_BOARD=compal_e99 >CONFIG_ARCH_BOARD_COMPALE99=y When the OS is configured, the top-level Makefile uses these definitions to create symbolic links: * arch/arm/src/chip will refer to arch/arm/src/calypso * arch/arm/include/chip will refer to arch/arm/include/calypso * arch/arm/include/board will refer to configs/compal_e99/include * arch/arm/src/board will refer to configs/compal_e99/src. And * include/arch will refer to to arch/arm/include So you can include ARM general header, calypso-specific, and board-specific header files like: #include ? ? ? ?// architecture (ARM) specific header files >#include ? // Chip (calypso) specific header files >#include // Board specific header files So, if you want to support the same processor (calypso) on a different board, say boardX, you could create a directory: configs/boardX And put boardX specific header files and source files in: configs/boardX/include >configs/boardX/src And put boardX software configurations under config/boardX/configY > - How we will handle our different ram config (boot from ram / flash), > can we use the loader to load part of the SDRAM if we don't fit in > SRAM completely ? I would think that these would correspond to different software build configuration directories under configs/BoardX. You also ask several memory related questions that I can't really answer. ?I think there may be some additional memory management requirements here: ? > - How we will handle the memory zones (SRAM / SDRAM / Flash / XIP from > flash (or just .rodata ?)) > - Memory allocator (handling zones ...). I think that'd be something > very useful. Currently we can only allocate msgb and that's a little > limiting. Right now, the memory allocator can handle multiple, discontinuous regions of memory. ?There is an interface called mm_addregion() that can always add a new block of memory to the memory pool. But there is mechanism now to select which region memory will be allocated from. ?malloc() is the only allocator for user programs. ?It will allocate memory only from the best fitting free memory chunk, but does not take into account any properties of the memory. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue May 24 07:59:52 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 24 May 2011 09:59:52 +0200 Subject: Nuttx for Calypso In-Reply-To: <82542.44346.qm@web31809.mail.mud.yahoo.com> References: <82542.44346.qm@web31809.mail.mud.yahoo.com> Message-ID: <20110524075952.GB10271@prithivi.gnumonks.org> Gregory, thanks a lot for your detailed response. On Mon, May 23, 2011 at 02:14:52PM -0700, Gregory Nutt wrote: > Nuttx is designed to support a hiearchical configuration: ?processor > family, chips in the family, boards that host the chips, and board > software configurations. [..] I think there is no obvious missing part from our requirements point of view. > config/boardX/configY > > - How we will handle our different ram config (boot from ram / flash), > > > can we use the loader to load part of the SDRAM if we don't fit in > > SRAM completely ? > > I would think that these would correspond to different software build > configuration directories under configs/BoardX. btw: there is no SDRAM. IT's SRAM, but there is external SRAM (slow) and internal SRAM (fast), as well eas external NOR flash. The normal procedure is to use section attributes in the code to determine which parts of the code get put into what part of memory. I think Nuttx doesn't care much about this, except that we will have custom linker scripts that will produce output for the different memory regions. I think the division will be roughly: * internal SRAM * super time critical code like FIQ handler for GSM TDMA * IRQ and FIQ stack * normal process stack? * external SRAM * external NOR flash * bootloader * .text segment of Nuttx, XIP * filesystem this is at least the configuration that would make most sense for the final version. During development (so far) we have been using no code in flash, and always loaded our code into RAM on every boot. This is definitely also a configuration that would make sense to have with Nuttx. But here it would probably make even more sense to have the Nuttx kernel in NOR flash and only load our application into external+internal SRAM. > You also ask several memory related questions that I can't really > answer. ?I think there may be some additional memory management > requirements here: ? > > - How we will handle the memory zones (SRAM / SDRAM / Flash / XIP from > > flash (or just .rodata ?)) XIP from flash should be a no-brainer, if the code is linked to the right address. I guess we simply divide the flash in one .text+.rodata part, and one filesystem partition. SRAM/SDRAM division as indicated above. Linker script will take care of correct linking. The only part I see is that our bootloader will have to load the different segments to different addresses correctly before jumping into Nuttx. > > - Memory allocator (handling zones ...). I think that'd be something > > very useful. Currently we can only allocate msgb and that's a little > > limiting. > > Right now, the memory allocator can handle multiple, discontinuous > regions of memory. ?There is an interface called mm_addregion() that > can always add a new block of memory to the memory pool. I think what our use case really wants is something that can efficiently create (and allocate from) pools of same-sized objects (like our 'struct msgb'). We'll probably have to code something custom for it, One real Nuttx related question that I have in mind though: Do you see an easy way how we can keep our 'application' code (that is all the GSM related stuff) in a separete source repository? I would like to come up with a situation where we have two repositories: 1) Nuttx (contains calypso uart/spi/i2c/lcd/... drivers and demo apps) 2) OsmocomBB (contains GSM layer1 and our application code) The reason for this is simple: The GSM code is still under a lot of flux, and we have many branches of it for different types of experiments. None of it will be useful to the general Nuttx user, as it is very specific to our project. Would it be as simple as to put a symlink pointing to the OsmocomBB repository somewhere in the Nuttx source tree? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spudarnia at yahoo.com Tue May 24 13:38:10 2011 From: spudarnia at yahoo.com (Gregory Nutt) Date: Tue, 24 May 2011 06:38:10 -0700 (PDT) Subject: Nuttx for Calypso In-Reply-To: <20110524075952.GB10271@prithivi.gnumonks.org> References: <82542.44346.qm@web31809.mail.mud.yahoo.com> <20110524075952.GB10271@prithivi.gnumonks.org> Message-ID: <43644.25789.qm@web31803.mail.mud.yahoo.com> Hi, Harald, > .. The normal procedure is to use section attributes in the code to > determine which parts of the code get put into what part of memory. > I think Nuttx doesn't care much about this, except that we will have > custom linker scripts that will produce output for the different > memory regions. The NuttX startup logic may have to care in that it may have to initialize data sections. ?Running in RAM, the start-up code may have to initialized .bss. ?But running out of FLASH, it will need to copy .data from into RAM. ?If you want executable code in internal SRAM, then that code would have to be copied into IRAM in either case. > ... ?During development (so far) we have been using no code > in flash, and always loaded our code into RAM on every boot. ?This is > definitely also a configuration that would make sense to have with > Nuttx. This worked fine that last time I used that configuration. ?There is a configuration option?CONFIG_BOOT_RUNFROMFLASH that would have to be deselected so that it would not try to initialize .data (and a different linker script would have to be used so that initialization data is not saved in FLASH) > ... But here it would probably make even more sense to have the > Nuttx kernel in NOR flash and only load our application into > external+internal SRAM. Are you talking about a separately linked, monolithic kernel (like a tiny Linux) and a separately built application image? ?The application image would then have to communicate to the monolithic kernel either through a call table or through system calls (or it would have to be linked with the kernel image at build time). Is that what you are thinking? ?I have implemented that configuration for the Cortex M3 (with supervisor/user mode and system calls). ?There there hooks are in place for ARM7 as well but more integration work is needed. > XIP from flash should be a no-brainer, if the code is linked to the > right address. ?I guess we simply divide the flash in one .text+.rodata > part, and one filesystem partition. XIP from FLASH can mean a lot of things. ?Running a NuttX image from flash truly is a no brainer. ?Running separate programs from FLASH is complex because dynamic linking is needed. ?NuttX supports a file format called NXFLAT that will let you run a program from an XIP file system (like ROMFS) but it needs a symbol table and NXFLAT loader (the moral equivalent of ld.so). > SRAM/SDRAM division as indicated above. ?Linker script will take care of > correct linking. ?The only part I see is that our bootloader will have > to load the different segments to different addresses correctly before > jumping into Nuttx. Or if NuttX is in FLASH, it can copy memory as it does now to initialize .data. > I think what our use case really wants is something that can efficiently > create (and allocate from) pools of same-sized objects (like our 'struct > msgb'). ?We'll probably have to code something custom for it, That seems appropriate. > One real Nuttx related question that I have in mind though: ?Do you see > an easy way how we can keep our 'application' code (that is all the GSM > related stuff) in a separete source repository? ?I would like to come up > with a situation where we have two repositories: > > 1) Nuttx (contains calypso uart/spi/i2c/lcd/... drivers and demo apps) > 2) OsmocomBB (contains GSM layer1 and our application code) > > The reason for this is simple: The GSM code is still under a lot of > flux, and we have many branches of it for different types of > experiments. ?None of it will be useful to the general Nuttx user, as it > is very specific to our project. Yes, I am sure you have noticed that NuttX is provided as two tarballs: ?One called nuttx-a.b.tar.gz that hold the core OS functionality in the nuttx/ directory and one called apps-a.b.tar.gz that holds sample application code in the apps/. ?That apps/ directory is meant to be a "break-away." ?You would discard the current apps/ directory (taking whatever is useful to you), and create your own application directory. When NuttX builds is needs to know the location of the apps directory. ?In the .config configuration file, you will see: # # General OS setup # # CONFIG_APPS_DIR - Identifies the relative path to the directory # ? that builds the application to link with NuttX. ?Default: ../apps ... #CONFIG_APPS_DIR= Note that CONFIG_APPS_DIR is not defined. ?And at the very bottom of the configuration file you will see: # Application configuration CONFIG_APPS_DIR="../apps" The version of CONFIG_APPS_DIR at the bottom of the .config file was not in the original defconfig file. ?It was appended by the configuration script. ?The configuration script noted that there was no application directory and looked around in some well known locations and picked one. However, if you were to have defined CONFIG_APPS_DIR=../calypso, then that is the application directory that would have been used. ?Your low-level drivers and ARM7 code code could be released inside of the common nuttx repository. ?But your application-specific code would reside in your custom application directory. Would you like to retain the Calypso code in the NuttX SVN repository? ?There are some long range advantages to that in that the Calypso code will maintained and will always be in sync with the latest NuttX. ?Licensing is the only issue. ?NuttX is BSD and Calypso is GPL. ?So the possibilities are: ?(1) You carry the NuttX code in your repository, (2) You release the Calypso OS (only) logic under BSD, or (3) I carry the Calypso code as GPL add-on. The base NuttX is BSD, but I have started putting together GPL add-on support. I would keep the GPL separate and there would be an INSTALL script. ?In the install script would require that the user agree to the GPL license. ?And if so, it would copy the GPL code into the NuttX source tree and replace the COPYING files, making the combined code GPL. ?This is kind of awkward, but if you would like to have a GPL version of NuttX for Calypso, then I think this could be the way to go. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue May 24 14:46:31 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 24 May 2011 16:46:31 +0200 Subject: Nuttx for Calypso In-Reply-To: <43644.25789.qm@web31803.mail.mud.yahoo.com> References: <82542.44346.qm@web31809.mail.mud.yahoo.com> <20110524075952.GB10271@prithivi.gnumonks.org> <43644.25789.qm@web31803.mail.mud.yahoo.com> Message-ID: > Yes, I am sure you have noticed that NuttX is provided as two tarballs: ?One > called nuttx-a.b.tar.gz that hold the core OS functionality in the nuttx/ > directory and one called apps-a.b.tar.gz that holds sample application code > in the apps/. ?That apps/ directory is meant to be a "break-away." ?You > would discard the current apps/ directory (taking whatever is useful to > you), and create your own application directory. Note that our "App" is more than a userspace "app" It's also a FIQ interrupt handler and some 'drivers' (for the GSM specific stuff like DSP / TPU and the RF / external chips). I'm also leaning toward having the board definition separate (at least part of them) since they'll including things like RFFE stuff that will only be useful for the GSM stuff. Cheers, Sylvain From ichgeh at l--putt.de Tue May 24 21:27:09 2011 From: ichgeh at l--putt.de (l--putt) Date: Tue, 24 May 2011 23:27:09 +0200 Subject: Nuttx for Calypso In-Reply-To: References: <82542.44346.qm@web31809.mail.mud.yahoo.com> <20110524075952.GB10271@prithivi.gnumonks.org> <43644.25789.qm@web31803.mail.mud.yahoo.com> Message-ID: <4DDC22AD.9000705@l--putt.de> On 24.05.2011 16:46, Sylvain Munaut wrote: > Note that our "App" is more than a userspace "app" Since we don't have a MMU, it's not much of a difference and there is no real userspace. We can still register IRQs etc. I would suggest that the GSM specific calls in board_init are moved to the "userspace" user_start function. For the MT6235, we need a cleaner API once it runs Linux. But for now on Nuttx, the current things are fine. > It's also a FIQ interrupt handler and some 'drivers' (for the GSM > specific stuff like DSP / TPU and the RF / external chips). I'll add FIQs and extend the interface to support them soon. > I'm also leaning toward having the board definition separate (at least > part of them) since they'll including things like RFFE stuff that will > only be useful for the GSM stuff. Well, the configs directory holds board specific stuff. However, it's probably not the appropriate place since it doesn't belong to the OS bit is GSM related. > Cheers, > > Sylvain > > From laforge at gnumonks.org Tue May 24 15:04:29 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 24 May 2011 17:04:29 +0200 Subject: Nuttx for Calypso In-Reply-To: <43644.25789.qm@web31803.mail.mud.yahoo.com> References: <82542.44346.qm@web31809.mail.mud.yahoo.com> <20110524075952.GB10271@prithivi.gnumonks.org> <43644.25789.qm@web31803.mail.mud.yahoo.com> Message-ID: <20110524150429.GL10271@prithivi.gnumonks.org> Hi Gregory, On Tue, May 24, 2011 at 06:38:10AM -0700, Gregory Nutt wrote: > > ... But here it would probably make even more sense to have the > > Nuttx kernel in NOR flash and only load our application into > > external+internal SRAM. > > Are you talking about a separately linked, monolithic kernel (like a > tiny Linux) and a separately built application image? ?The application > image would then have to communicate to the monolithic kernel either > through a call table or through system calls (or it would have to be > linked with the kernel image at build time). Well, the call table or syscall approach may be nice to have in the future, but even linking it at build time (so it knows the addresses of the various kernel functions it wants to call) would be fine for me right now. > Is that what you are thinking? ?I have implemented that configuration > for the Cortex M3 (with supervisor/user mode and system calls). ?There > there hooks are in place for ARM7 as well but more integration work is > needed. I've tried to compile the syscall code for ARM7TDMI and figured it is not complete yet. As indicated above, I don't think it's a big deal. We shouldn't try to put too much effort into changing/extending Nuttx and rather use what's there and focus on our GSM related work. > > XIP from flash should be a no-brainer, if the code is linked to the > > right address. ?I guess we simply divide the flash in one .text+.rodata > > part, and one filesystem partition. > > XIP from FLASH can mean a lot of things. ?Running a NuttX image from > flash truly is a no brainer. ? that's what I was primarily thinking of. > Running separate programs from FLASH is complex because dynamic > linking is needed. ?NuttX supports a file format called NXFLAT that > will let you run a program from an XIP file system (like ROMFS) but it > needs a symbol table and NXFLAT loader (the moral equivalent of > ld.so). if those things exist and work for ARM7TDMI: great, let's use them. If not, we can live with that, too. The idea of separate kernel and application images is simple: We normally download our code via a 115,200 bps serial line, and to speed up development it would be great to not re-download "all of" nuttx again, but only the GSM related applicaitons. > > One real Nuttx related question that I have in mind though: ?Do you see > > an easy way how we can keep our 'application' code (that is all the GSM > > related stuff) in a separete source repository? ?I would like to come up > > with a situation where we have two repositories: > > > > 1) Nuttx (contains calypso uart/spi/i2c/lcd/... drivers and demo apps) > > 2) OsmocomBB (contains GSM layer1 and our application code) > > > > The reason for this is simple: The GSM code is still under a lot of > > flux, and we have many branches of it for different types of > > experiments. ?None of it will be useful to the general Nuttx user, as it > > is very specific to our project. > > Yes, I am sure you have noticed that NuttX is provided as two > tarballs: ? Actually I haven't noticed since I rarely use any release tarballs of FOSS projects but simply the contents of the revision control system. But I've noticed the nuttx/ and apps/ directories ;) > When NuttX builds is needs to know the location of the apps directory. > ?In the .config configuration file, you will see: > # > # General OS setup > # > # CONFIG_APPS_DIR - Identifies the relative path to the directory > # ? that builds the application to link with NuttX. ?Default: ../apps > ... > #CONFIG_APPS_DIR= great, we will simply use that feature then. > Would you like to retain the Calypso code in the NuttX SVN repository? > There are some long range advantages to that in that the Calypso code > will maintained and will always be in sync with the latest NuttX. yes, this is what I had in mind. >?Licensing is the only issue. ?NuttX is BSD and Calypso is GPL. ?So > the possibilities are: ?(1) You carry the NuttX code in your > repository, (2) You release the Calypso OS (only) logic under BSD, or > (3) I carry the Calypso code as GPL add-on. We've already briefly discussed this either here or on IRC, and I have no problems with the 'standard' non-gsm port+drivers to be under a BSD license. We would have to see if all developers agree, but I don't see big problems here. BTW, since we're in this discussion anyway: The synchronous part of the GSM Layer1 right runs in FIQ context, to ensure the tight timing of the TDMA nature of GSM. All non-GSM related interrupts are normal IRQs, so they can be pre-empted by the GSM FIQ. Do you see any problems with this? Is there something in the Nuttx ARM7TDMI related code that disables FIQs or otherwise interferes with them? Thanks once again for all your support, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ichgeh at l--putt.de Tue May 24 22:13:31 2011 From: ichgeh at l--putt.de (l--putt) Date: Wed, 25 May 2011 00:13:31 +0200 Subject: Nuttx for Calypso In-Reply-To: <20110524150429.GL10271@prithivi.gnumonks.org> References: <82542.44346.qm@web31809.mail.mud.yahoo.com> <20110524075952.GB10271@prithivi.gnumonks.org> <43644.25789.qm@web31803.mail.mud.yahoo.com> <20110524150429.GL10271@prithivi.gnumonks.org> Message-ID: <4DDC2D8B.5030307@l--putt.de> Hi all, after that bunch of patches, some more thoughts: On 24.05.2011 17:04, Harald Welte wrote: > Hi Gregory, > > On Tue, May 24, 2011 at 06:38:10AM -0700, Gregory Nutt wrote: > >> Running separate programs from FLASH is complex because dynamic >> linking is needed. NuttX supports a file format called NXFLAT that >> will let you run a program from an XIP file system (like ROMFS) but it >> needs a symbol table and NXFLAT loader (the moral equivalent of >> ld.so). > if those things exist and work for ARM7TDMI: great, let's use them. > If not, we can live with that, too. The idea of separate kernel and > application images is simple: We normally download our code via a > 115,200 bps serial line, and to speed up development it would be great > to not re-download "all of" nuttx again, but only the GSM related > applicaitons. My plan is to bring up NuttShell, add NXFLAT support and put that into flash. We can then load a ramfs image by whatever means and execute the app. The problem is that the UART driver is still a hack. I'm reusing the Osmocom code (with IRQ stuff modified) and wrapped it into a Nuttx device structure. However, this is one-way phone to host for the time being. The current UART driver is closely tied to sercomm and the console, respectively. A cleaner seperation might help ports to other devices, new protocols, etc. Before I spend more work on the current code: Is the sercomm protocol successful and will stay? What interface to userspace do you suggest? Should be something that works on Linux if our stuff ends up on more powerful devices. My proposal: A char device /dev/sercomm Each time you open it, it starts a new channel. With ioctl, you can change the channel. Each write is send as a message. Nuttx has buffers for stdio and hence will take care that there are not too many messages (I hope :P ) The receive part: a blocking read? >> When NuttX builds is needs to know the location of the apps directory. >> In the .config configuration file, you will see: >> # >> # General OS setup >> # >> # CONFIG_APPS_DIR - Identifies the relative path to the directory >> # that builds the application to link with NuttX. Default: ../apps >> ... >> #CONFIG_APPS_DIR= > great, we will simply use that feature then. If you don't see any problems, I would like to go one step further and move some of the hardware initialization like dsp, dma,... into user_main. Advantage: I won't go into the binary if you don't need it (hello_world, charger debugging, whatever) > BTW, since we're in this discussion anyway: The synchronous part of the > GSM Layer1 right runs in FIQ context, to ensure the tight timing of the > TDMA nature of GSM. All non-GSM related interrupts are normal IRQs, so > they can be pre-empted by the GSM FIQ. > > Do you see any problems with this? Is there something in the Nuttx > ARM7TDMI related code that disables FIQs or otherwise interferes with > them? I thought local_fiq_disable() in secomm_cons messes around with FIQs. Why is that save or what does it actually do? > Thanks once again for all your support, > Harald Regards, Stefan From 246tnt at gmail.com Tue May 24 22:27:09 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 25 May 2011 00:27:09 +0200 Subject: Nuttx for Calypso In-Reply-To: <4DDC2D8B.5030307@l--putt.de> References: <82542.44346.qm@web31809.mail.mud.yahoo.com> <20110524075952.GB10271@prithivi.gnumonks.org> <43644.25789.qm@web31803.mail.mud.yahoo.com> <20110524150429.GL10271@prithivi.gnumonks.org> <4DDC2D8B.5030307@l--putt.de> Message-ID: > Before I spend more work on the current code: Is the sercomm protocol > successful and will stay? What interface to userspace do you suggest? I think that yes sercomm is useful and should stay but be 'separate'. So my vision is to have a real 'normal' uart driver. Then 'above' that, we have a 'sercomm' layer that allows multiple protocol to be 'registred' over it and one of those would be a 'virtual' uart driver that would have for nuttx the same interface as any other driver). Then the gsm ass would just register another DLCI handler for the L1CTL link. And you just configure the 'secomm' layer to use any nuttx uart (in our case the ) as physical link. |Ser com UART | Sercom L1CTL | Sercomm xxx | ------------------------------------------- Sercomm layer ------------------------------------------- Phys UART > My proposal: A char device /dev/sercomm Each time you > open it, it starts a new channel. With ioctl, you can change the > channel. Each write is send as a message. Nuttx has buffers for stdio > and hence will take care that there are not too many messages (I hope :P > ) The receive part: a blocking read? On linux, yes that sounds good, but I would also have an internal API (for the kernel) so that you can create a real /dev/ttyXXX driver that talks over sercomm as well. > If you don't see any problems, I would like to go one step further and > move some of the hardware initialization like dsp, dma,... into > user_main. Advantage: I won't go into the binary if you don't need it > (hello_world, charger debugging, whatever) DSP is really GSM specific and should not be there IMHO because it's one of those things that can change (especially all the API zone init and the patches loading). It's also completely useless for anything but GSM. > I thought local_fiq_disable() in secomm_cons messes around with FIQs. > Why is that save or what does it actually do? it's to protect the state of the various queues and some shared state. From laforge at gnumonks.org Wed May 25 06:19:20 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 25 May 2011 08:19:20 +0200 Subject: Nuttx for Calypso In-Reply-To: <4DDC2D8B.5030307@l--putt.de> References: <82542.44346.qm@web31809.mail.mud.yahoo.com> <20110524075952.GB10271@prithivi.gnumonks.org> <43644.25789.qm@web31803.mail.mud.yahoo.com> <20110524150429.GL10271@prithivi.gnumonks.org> <4DDC2D8B.5030307@l--putt.de> Message-ID: <20110525061920.GB24513@prithivi.gnumonks.org> Hi Stefan, On Wed, May 25, 2011 at 12:13:31AM +0200, l--putt wrote: > Before I spend more work on the current code: Is the sercomm protocol > successful and will stay? yes. > What interface to userspace do you suggest? each DLC should be a separate device e.g. /dev/ttyHDLC0.., so a userspace process can simply open one DLC and read/write to it using stadard read/write calls. > Should be something that works on Linux if our stuff ends up on more > powerful devices. My proposal: A char device /dev/sercomm Each time you > open it, it starts a new channel. No, please make it explicit and have one device for each DLC Automatically assigning a channel is not a useful feature. > With ioctl, you can change the channel. then you would have to do that ioctl() every time. I like the idea of one device per DLC better. > Each write is send as a message. Nuttx has buffers for stdio and hence > will take care that there are not too many messages (I hope :P > ) > The receive part: a blocking read? either blocking read, or the user can set O_NONBLOCK and do select/poll (not sure if nuttx supports that, but at least on Linux it would work) In terms of Linux there may already be a more generic serial multiplexer protocol that we can re-use. Not sure if it finally has a TS07.10 multiplexer, e.g. If yes, the we may consider switching to TS07.10 instead of our homebrew HDLC. In any case, on Linux the multiplex driver would be bound as a line discipline to the real serial port, and offers N virtual serial ports for the N DLCs. > > Do you see any problems with this? Is there something in the Nuttx > > ARM7TDMI related code that disables FIQs or otherwise interferes with > > them? > > I thought local_fiq_disable() in secomm_cons messes around with FIQs. > Why is that save or what does it actually do? it is neccessary as we also want to log messages from the L1. Right now the L1 (from FIQ) submits a log message, and the normal code in the UART driver fetches those messages and writes them to the UART. You need some kind of locking/mutex for a very short time to protect the queue of messages here. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From squalyl at gmail.com Thu May 19 10:58:48 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Thu, 19 May 2011 12:58:48 +0200 Subject: http git for nuttx-bb Message-ID: Hello, I installed a git mirror with http access at http://repo.or.cz/r/nuttx-bb.git Regards Sebastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Fri May 20 10:03:54 2011 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Fri, 20 May 2011 12:03:54 +0200 Subject: status report layer1 and layer23 Message-ID: hi, i just fixed some locking issues the last days. fix will follow. it took a bit longer, because there were some race conditions. it took up to about one hour until it crashed. my way to detect the area where the crash happened, was to turn on buzzer before that area, and turn it off after that area. after many hours of approximation, i finally found out that the major crash happend during _talloc_zero. (first it looks for a free memory chunk, then it allocates it.) since it can be called from all contexts (main, irq, fiq), it need to be locked against any interrupt, otherwise the memory chunk can be assigned multiple times. (the process of _talloc_free is "atomic" and requires no locking.) because it seems pretty stable, i think it is time to merge some branches into the master. (i made a 6 hours call yesterday. and no crash after bugfix ever since.) i will do that together with sylvain, if we find the time this weekend. currently i use the jolly/voice together with the sylvain/traffic branch. i am able to use an isdn phone togehter with linux-call-router and make/receive calls. audio is passed both ways. i think this is a stage where it actually become "usable". (if not moving arround.) one of my major work for the next weeks/months will be the neighbour cell measurement, cell re-selection, and handover. this is essential when moving with the phone. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun May 22 19:45:19 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 May 2011 21:45:19 +0200 Subject: GSMTAP now creates a locally bound receive socket Message-ID: <20110522194519.GU4243@prithivi.gnumonks.org> Hi! libosmocore >= 0.3.1 and the current osmocom-bb code will now generate not only the sending GSMTAP UDP socket, but also a locally-bound receive socket. This avoids the manual start of "nc -l -u -p 4729 >/dev/null" or iptables rules to drop the UDP packets. The local receive socket is only created if the GSMTAP IP address is a locally configured address on any of your network interfaces. So sending it to 127.0.0.1 should work well. Don't be surprised if you happen to see GSMTAP over IPv6, I'm now using getaddrinfo() and related functions, i.e. "loopback" may now resolve to ::1 instead of 127.0.0.1 Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gianni at scaramanga.co.uk Mon May 23 19:20:24 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 23 May 2011 20:20:24 +0100 Subject: GSMTAP now creates a locally bound receive socket In-Reply-To: <20110522194519.GU4243@prithivi.gnumonks.org> References: <20110522194519.GU4243@prithivi.gnumonks.org> Message-ID: <1306178424.19876.9.camel@deckard> On Sun, 2011-05-22 at 21:45 +0200, Harald Welte wrote: > Hi! > > libosmocore >= 0.3.1 and the current osmocom-bb code will now generate > not only the sending GSMTAP UDP socket, but also a locally-bound receive > socket. > > This avoids the manual start of "nc -l -u -p 4729 >/dev/null" or > iptables rules to drop the UDP packets. > > The local receive socket is only created if the GSMTAP IP address is a > locally configured address on any of your network interfaces. So > sending it to 127.0.0.1 should work well. > > Don't be surprised if you happen to see GSMTAP over IPv6, I'm now using > getaddrinfo() and related functions, i.e. "loopback" may now resolve to > ::1 instead of 127.0.0.1 > > Regards, > Harald Could these changes be related to the sudden crashes I am having since enabling test sim in mobile (with no -i specified) ? Following patch fixes it. diff --git a/src/shared/libosmocore/src/gsmtap_util.c b/src/shared/libosmocore/src/gsmtap_util.c index 5c68b6a..2de4beb 100644 --- a/src/shared/libosmocore/src/gsmtap_util.c +++ b/src/shared/libosmocore/src/gsmtap_util.c @@ -148,6 +148,11 @@ int gsmtap_source_add_sink_fd(int gsmtap_fd) int gsmtap_sendmsg(struct gsmtap_inst *gti, struct msgb *msg) { + if ( NULL == gti ) { + msgb_free(msg); + return 0; + } + if (gti->ofd_wq_mode) return osmo_wqueue_enqueue(>i->wq, msg); else { From laforge at gnumonks.org Mon May 23 20:12:45 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 23 May 2011 22:12:45 +0200 Subject: GSMTAP now creates a locally bound receive socket In-Reply-To: <1306178424.19876.9.camel@deckard> References: <20110522194519.GU4243@prithivi.gnumonks.org> <1306178424.19876.9.camel@deckard> Message-ID: <20110523201245.GM7651@prithivi.gnumonks.org> On Mon, May 23, 2011 at 08:20:24PM +0100, Gianni Tedesco wrote: > Could these changes be related to the sudden crashes I am having since > enabling test sim in mobile (with no -i specified) ? yes. > Following patch fixes it. this has already been fixed in libosmocore.git, just the copy in osmocom-bb.git has not been updated as it seems. I'm looking into it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From info at sharonsoft.com Mon May 23 06:35:39 2011 From: info at sharonsoft.com (Sun Ich) Date: Sun, 22 May 2011 23:35:39 -0700 (PDT) Subject: Strange error Message-ID: <534027.32207.qm@web1103.biz.mail.sk1.yahoo.com> Hi When I try to load any program from firmware/board/compal_e88/ to my C118 phone, I receive error below: ioctl(TIOCGSERIAL): Invalid argument I upload program successfully and I receive DOWNLOAD ACK from phone properly, but then I receive this strange ioctl error. I'm running Ubuntu 9 and I tried to load compal_dsp_dump.compalram.bin layer1.compalram.bin loader.compalram.bin Result is same for all of the above. Please advice. Thanks From wpatan at gmail.com Mon May 23 07:28:01 2011 From: wpatan at gmail.com (wpatan) Date: Mon, 23 May 2011 00:28:01 -0700 (PDT) Subject: Strange error In-Reply-To: <534027.32207.qm@web1103.biz.mail.sk1.yahoo.com> References: <534027.32207.qm@web1103.biz.mail.sk1.yahoo.com> Message-ID: <1306135681770-2974305.post@n3.nabble.com> Are you using the "burst" branch? I've encountered this error once... It shows up if you try to use a "non-standard" baud rate on a non-FTDI based cable. If you're planning to play with the "burst" branch, then you're required to use an FTDI cable. - cheers wpatan -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Strange-error-tp2974210p2974305.html Sent from the baseband-devel mailing list archive at Nabble.com. From uli.radiotux at googlemail.com Mon May 23 11:43:35 2011 From: uli.radiotux at googlemail.com (Uli Kleemann) Date: Mon, 23 May 2011 13:43:35 +0200 Subject: osmocon compal_e88/loader.compalram.bin Message-ID: Hi fellows, I am new at osmocon and I would like to ask fpr some help about flashing the firmware on my C118. I build the software as described on Ubuntu11.0.4 using gnuarm-3.4.3. I use the Motorola T191 serial-cable on an Prolific Technology, Inc. PL2303 Serial Port USB-Serial adapter. (module USB-serial is loaded) when I startosmocon like this: ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin all I get is that: got 2 bytes from modem, data looks like: fe 00 .. got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . Can anybody give me an advice how to fix that? Thanks in advance Uli -- Uli Kleemann From gianni at scaramanga.co.uk Mon May 23 22:51:56 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 23 May 2011 23:51:56 +0100 Subject: osmocon compal_e88/loader.compalram.bin In-Reply-To: References: Message-ID: <1306191116.19876.38.camel@deckard> On Mon, 2011-05-23 at 13:43 +0200, Uli Kleemann wrote: > Hi fellows, > > I am new at osmocon and I would like to ask fpr some help about > flashing the firmware on my C118. > > I build the software as described on Ubuntu11.0.4 using gnuarm-3.4.3. > I use the Motorola T191 serial-cable on an Prolific Technology, Inc. > PL2303 Serial Port USB-Serial adapter. (module USB-serial is loaded) > > when I startosmocon like this: > ./osmocon -p /dev/ttyUSB0 -m c123xor > ../../target/firmware/board/compal_e88/loader.compalram.bin > > all I get is that: > > got 2 bytes from modem, data looks like: fe 00 .. > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . Just looks like noise from plugging the cable in to the phone. > Can anybody give me an advice how to fix that? Did you press the power button on the phone? Just a quick tap is required, not a long press like you would normally do to turn it on. Gianni From uli.radiotux at googlemail.com Wed May 25 16:48:48 2011 From: uli.radiotux at googlemail.com (Uli Kleemann) Date: Wed, 25 May 2011 18:48:48 +0200 Subject: osmocon compal_e88/loader.compalram.bin In-Reply-To: <1306191116.19876.38.camel@deckard> References: <1306191116.19876.38.camel@deckard> Message-ID: Hi Gianni, Many thanks for your answer. Yes I did press the power button several times, shortly. All I got all I still get is this: /install/osmocom-bb/src/host/osmocon$ ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin got 2 bytes from modem, data looks like: fe 00 .. got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . Regards, Uli 2011/5/24, Gianni Tedesco : > On Mon, 2011-05-23 at 13:43 +0200, Uli Kleemann wrote: >> Hi fellows, >> >> I am new at osmocon and I would like to ask fpr some help about >> flashing the firmware on my C118. >> >> I build the software as described on Ubuntu11.0.4 using gnuarm-3.4.3. >> I use the Motorola T191 serial-cable on an Prolific Technology, Inc. >> PL2303 Serial Port USB-Serial adapter. (module USB-serial is loaded) >> >> when I startosmocon like this: >> ./osmocon -p /dev/ttyUSB0 -m c123xor >> ../../target/firmware/board/compal_e88/loader.compalram.bin >> >> all I get is that: >> >> got 2 bytes from modem, data looks like: fe 00 .. >> got 1 bytes from modem, data looks like: 00 . >> got 1 bytes from modem, data looks like: 00 . >> got 1 bytes from modem, data looks like: 00 . >> got 1 bytes from modem, data looks like: 00 . >> got 1 bytes from modem, data looks like: 00 . >> got 1 bytes from modem, data looks like: 00 . > > Just looks like noise from plugging the cable in to the phone. > >> Can anybody give me an advice how to fix that? > > Did you press the power button on the phone? Just a quick tap is > required, not a long press like you would normally do to turn it on. > > Gianni > > -- Uli Kleemann From uli.radiotux at googlemail.com Wed May 25 18:52:44 2011 From: uli.radiotux at googlemail.com (Uli Kleemann) Date: Wed, 25 May 2011 20:52:44 +0200 Subject: osmocon compal_e88/loader.compalram.bin In-Reply-To: <131013.53911.qm@web112103.mail.gq1.yahoo.com> References: <131013.53911.qm@web112103.mail.gq1.yahoo.com> Message-ID: I took out the battery and I got that: got 2 bytes from modem, data looks like: 3c 00 <. got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . So I took out the SIM Card, too but nothing changed. 2011/5/25, eisencah eisenach : > Try taking out the battery too. > > --- On Wed, 5/25/11, Uli Kleemann wrote: > > From: Uli Kleemann > Subject: Re: osmocon compal_e88/loader.compalram.bin > To: "Gianni Tedesco" > Cc: baseband-devel at lists.osmocom.org > Date: Wednesday, May 25, 2011, 7:48 PM > > Hi Gianni, > > Many thanks for your answer. Yes I did press the power button several > times, shortly. > > All I got all I still get is this: > > /install/osmocom-bb/src/host/osmocon$ ./osmocon -p /dev/ttyUSB0 -m > c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin > got 2 bytes from modem, data looks like: fe 00 .. > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > > Regards, > > Uli > > 2011/5/24, Gianni Tedesco : >> On Mon, 2011-05-23 at 13:43 +0200, Uli Kleemann wrote: >>> Hi fellows, >>> >>> I am new at osmocon and I would like to ask fpr some help about >>> flashing the firmware on my C118. >>> >>> I build the software as described on Ubuntu11.0.4 using gnuarm-3.4.3. >>> I use the Motorola T191 serial-cable on an Prolific Technology, Inc. >>> PL2303 Serial Port USB-Serial adapter. (module USB-serial is loaded) >>> >>> when I startosmocon like this: >>> ./osmocon -p /dev/ttyUSB0 -m c123xor >>> ../../target/firmware/board/compal_e88/loader.compalram.bin >>> >>> all I get is that: >>> >>> got 2 bytes from modem, data looks like: fe 00 .. >>> got 1 bytes from modem, data looks like: 00 . >>> got 1 bytes from modem, data looks like: 00 . >>> got 1 bytes from modem, data looks like: 00 . >>> got 1 bytes from modem, data looks like: 00 . >>> got 1 bytes from modem, data looks like: 00 . >>> got 1 bytes from modem, data looks like: 00 . >> >> Just looks like noise from plugging the cable in to the phone. >> >>> Can anybody give me an advice how to fix that? >> >> Did you press the power button on the phone? Just a quick tap is >> required, not a long press like you would normally do to turn it on. >> >> Gianni >> >> > > > -- > Uli Kleemann > > -- Uli Kleemann From meierk at informatik.uni-freiburg.de Wed May 25 19:43:50 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Wed, 25 May 2011 21:43:50 +0200 Subject: osmocon compal_e88/loader.compalram.bin In-Reply-To: References: <131013.53911.qm@web112103.mail.gq1.yahoo.com> Message-ID: <4DDD5BF6.3040406@informatik.uni-freiburg.de> Am 25.05.2011 20:52, schrieb Uli Kleemann: > I took out the battery and I got that: > got 2 bytes from modem, data looks like: 3c 00<. > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 00 . I think there is something wrong with your cable. Are you sure is has an output voltage not higher than 3,3V? If you have a oscilloscope, use it to check check the cable and the phone. More information on the data cable can found in the wiki and in the mail archive: http://www.osmocom.org/trac/wiki/CalypsoSerialCable http://baseband-devel.722152.n3.nabble.com/hmm-sorry-data-cable-question-td2419703.html#a2965249 Regards Konrad From labadjala6 at gmail.com Tue May 24 20:17:58 2011 From: labadjala6 at gmail.com (labad jala) Date: Tue, 24 May 2011 22:17:58 +0200 Subject: hmmm, data cable question Message-ID: Thanks again. I measured 4v using a USB/RS232 (U232-P9) adapatator attached to a laptop and also a desktop + "T191" that looks exactly like http://www.cellcorner.com/xshp/unlock-phone-codes/motorola-t190-t191-t193-unlock-data-cable.html.Please, did someone buy this one and had good voltage and results? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weberbe at ee.ethz.ch Tue May 24 20:30:18 2011 From: weberbe at ee.ethz.ch (weberbe at ee.ethz.ch) Date: Tue, 24 May 2011 22:30:18 +0200 Subject: hmmm, data cable question In-Reply-To: References: Message-ID: <20110524223018.104221rokjhq28gq@email.ee.ethz.ch> Hi there I am using the below mentioned cable, never measured the voltage but it works fine. The plastic around the plug is a little big though, doesn't fit so well into the C123. Ben Quoting "labad jala" : > Thanks again. I measured 4v using a USB/RS232 (U232-P9) adapatator attached > to a laptop and also a desktop + "T191" that looks exactly like > http://www.cellcorner.com/xshp/unlock-phone-codes/motorola-t190-t191-t193-unlock-data-cable.html.Please, > did someone buy this one and had good voltage and results? Regards. > From ichgeh at l--putt.de Tue May 24 21:04:46 2011 From: ichgeh at l--putt.de (l--putt) Date: Tue, 24 May 2011 23:04:46 +0200 Subject: [PATCH 1/4] Initial support for Nuttx on TI Calypso platform Message-ID: <4DDC1D6E.4050906@l--putt.de> From ichgeh at l--putt.de Tue May 24 18:52:54 2011 From: ichgeh at l--putt.de (Stefan Richter) Date: Tue, 24 May 2011 20:52:54 +0200 Subject: [PATCH 1/4] Initial support for Nuttx on TI Calypso platform: Add calypso chip and compal E99 board to Nuttx targets linker script no-brainer / dummy files Osmocom's debug.h, defines.h, memory.h for compatibility Message-ID: --- nuttx/arch/arm/include/calypso/debug.h | 31 ++ nuttx/arch/arm/include/calypso/defines.h | 18 ++ nuttx/arch/arm/include/calypso/memory.h | 28 ++ nuttx/arch/arm/src/Makefile | 2 +- nuttx/arch/arm/src/calypso/Make.defs | 53 ++++ nuttx/arch/arm/src/calypso/calypso_head.S | 23 ++ nuttx/arch/arm/src/calypso/calypso_lowputc.S | 136 +++++++++ nuttx/arch/arm/src/calypso/chip.h | 204 +++++++++++++ nuttx/configs/compal_e99/include/board.h | 6 + nuttx/configs/compal_e99/ld.script | 126 ++++++++ nuttx/configs/compal_e99/ostest/Make.defs | 123 ++++++++ nuttx/configs/compal_e99/ostest/appconfig | 39 +++ nuttx/configs/compal_e99/ostest/defconfig | 414 ++++++++++++++++++++++++++ nuttx/configs/compal_e99/ostest/setenv.sh | 46 +++ nuttx/configs/compal_e99/src/Makefile | 80 +++++ nuttx/configs/compal_e99/src/dummy.c | 1 + 16 files changed, 1329 insertions(+), 1 deletions(-) create mode 100644 nuttx/arch/arm/include/calypso/debug.h create mode 100644 nuttx/arch/arm/include/calypso/defines.h create mode 100644 nuttx/arch/arm/include/calypso/memory.h create mode 100644 nuttx/arch/arm/src/calypso/Make.defs create mode 100644 nuttx/arch/arm/src/calypso/calypso_head.S create mode 100644 nuttx/arch/arm/src/calypso/calypso_lowputc.S create mode 100644 nuttx/arch/arm/src/calypso/chip.h create mode 100644 nuttx/configs/compal_e99/include/board.h create mode 100644 nuttx/configs/compal_e99/ld.script create mode 100644 nuttx/configs/compal_e99/ostest/Make.defs create mode 100644 nuttx/configs/compal_e99/ostest/appconfig create mode 100644 nuttx/configs/compal_e99/ostest/defconfig create mode 100755 nuttx/configs/compal_e99/ostest/setenv.sh create mode 100644 nuttx/configs/compal_e99/src/Makefile create mode 100644 nuttx/configs/compal_e99/src/dummy.c diff --git a/nuttx/arch/arm/include/calypso/debug.h b/nuttx/arch/arm/include/calypso/debug.h new file mode 100644 index 0000000..27c4185 --- /dev/null +++ b/nuttx/arch/arm/include/calypso/debug.h @@ -0,0 +1,31 @@ +#ifndef _DEBUG_H +#define _DEBUG_H + +#ifndef ARRAY_SIZE +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) +#endif + +/* + * Check at compile time that something is of a particular type. + * Always evaluates to 1 so you may use it easily in comparisons. + */ +#define typecheck(type,x) \ +({ type __dummy; \ + typeof(x) __dummy2; \ + (void)(&__dummy == &__dummy2); \ + 1; \ +}) + +#ifdef DEBUG +#define dputchar(x) putchar(x) +#define dputs(x) puts(x) +#define dphex(x,y) phex(x,y) +#define printd(x, args ...) printf(x, ## args) +#else +#define dputchar(x) +#define dputs(x) +#define dphex(x,y) +#define printd(x, args ...) +#endif + +#endif /* _DEBUG_H */ diff --git a/nuttx/arch/arm/include/calypso/defines.h b/nuttx/arch/arm/include/calypso/defines.h new file mode 100644 index 0000000..3c8732f --- /dev/null +++ b/nuttx/arch/arm/include/calypso/defines.h @@ -0,0 +1,18 @@ + +#ifndef _DEFINES_H +#define _DEFINES_H + +#define __attribute_const__ __attribute__((__const__)) + +/* type properties */ +#define __packed __attribute__((packed)) +#define __aligned(alignment) __attribute__((aligned(alignment))) +#define __unused __attribute__((unused)) + +/* linkage */ +#define __section(name) __attribute__((section(name))) + +/* force placement in zero-waitstate memory */ +#define __ramtext __section(".ramtext") + +#endif /* !_DEFINES_H */ diff --git a/nuttx/arch/arm/include/calypso/memory.h b/nuttx/arch/arm/include/calypso/memory.h new file mode 100644 index 0000000..b0a0490 --- /dev/null +++ b/nuttx/arch/arm/include/calypso/memory.h @@ -0,0 +1,28 @@ +#ifndef _MEMORY_H +#define _MEMORY_H + +#define __arch_getb(a) (*(volatile unsigned char *)(a)) +#define __arch_getw(a) (*(volatile unsigned short *)(a)) +#define __arch_getl(a) (*(volatile unsigned int *)(a)) + +#define __arch_putb(v,a) (*(volatile unsigned char *)(a) = (v)) +#define __arch_putw(v,a) (*(volatile unsigned short *)(a) = (v)) +#define __arch_putl(v,a) (*(volatile unsigned int *)(a) = (v)) + +#define __raw_writeb(v,a) __arch_putb(v,a) +#define __raw_writew(v,a) __arch_putw(v,a) +#define __raw_writel(v,a) __arch_putl(v,a) + +#define __raw_readb(a) __arch_getb(a) +#define __raw_readw(a) __arch_getw(a) +#define __raw_readl(a) __arch_getl(a) + +#define writeb(v,a) __arch_putb(v,a) +#define writew(v,a) __arch_putw(v,a) +#define writel(v,a) __arch_putl(v,a) + +#define readb(a) __arch_getb(a) +#define readw(a) __arch_getw(a) +#define readl(a) __arch_getl(a) + +#endif /* _MEMORY_H */ diff --git a/nuttx/arch/arm/src/Makefile b/nuttx/arch/arm/src/Makefile index 22327af..2530c05 100644 --- a/nuttx/arch/arm/src/Makefile +++ b/nuttx/arch/arm/src/Makefile @@ -67,7 +67,7 @@ SRCS = $(ASRCS) $(CSRCS) OBJS = $(AOBJS) $(COBJS) LDFLAGS = $(ARCHSCRIPT) -EXTRA_LIBS = +#EXTRA_LIBS = LINKLIBS = ifeq ($(WINTOOL),y) diff --git a/nuttx/arch/arm/src/calypso/Make.defs b/nuttx/arch/arm/src/calypso/Make.defs new file mode 100644 index 0000000..d1c14d4 --- /dev/null +++ b/nuttx/arch/arm/src/calypso/Make.defs @@ -0,0 +1,53 @@ +############################################################################ +# calypso/Make.defs +# +# Copyright (C) 2007 Gregory Nutt. All rights reserved. +# Author: Gregory Nutt +# +# Copyright (C) 2011 Stefan Richter. All rights reserved. +# Author: Stefan Richter +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# 3. Neither the name Gregory Nutt nor the names of its contributors may be +# used to endorse or promote products derived from this software +# without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS +# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED +# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. +# +############################################################################ + +HEAD_ASRC = calypso_head.S + +CMN_ASRCS = up_saveusercontext.S up_fullcontextrestore.S up_vectors.S \ + up_nommuhead.S +CMN_CSRCS = up_allocateheap.c up_assert.c up_blocktask.c up_copystate.c \ + up_createstack.c up_dataabort.c up_mdelay.c up_udelay.c up_doirq.c \ + up_exit.c up_idle.c up_initialstate.c up_initialize.c \ + up_interruptcontext.c up_prefetchabort.c up_releasepending.c \ + up_releasestack.c up_reprioritizertr.c up_schedulesigaction.c \ + up_sigdeliver.c up_syscall.c up_unblocktask.c \ + up_undefinedinsn.c up_usestack.c + +CHIP_ASRCS = calypso_lowputc.S +CHIP_CSRCS = calypso_irq.c calypso_timer.c calypso_heap.c \ + clock.c diff --git a/nuttx/arch/arm/src/calypso/calypso_head.S b/nuttx/arch/arm/src/calypso/calypso_head.S new file mode 100644 index 0000000..eb83b68 --- /dev/null +++ b/nuttx/arch/arm/src/calypso/calypso_head.S @@ -0,0 +1,23 @@ +/* Place a branch to the real head at the entry point */ +.section .text.start + b __start + + +/* Exception Vectors like they are needed for the exception vector + indirection of the internal boot ROM. The following section must + be liked to appear at 0x80001c */ +.section .text.exceptions +_undef_instr: + b up_vectorundefinsn +_sw_interr: + b up_vectorswi +_prefetch_abort: + b up_vectorprefetch +_data_abort: + b up_vectordata +_reserved: + b _reserved +_irq: + b up_vectorirq +_fiq: + b up_vectorfiq diff --git a/nuttx/arch/arm/src/calypso/calypso_lowputc.S b/nuttx/arch/arm/src/calypso/calypso_lowputc.S new file mode 100644 index 0000000..bf30fe0 --- /dev/null +++ b/nuttx/arch/arm/src/calypso/calypso_lowputc.S @@ -0,0 +1,136 @@ +/************************************************************************** + * calypso/calypso_lowputc.S + * + * Copyright (C) 2011 Stefan Richter. All rights reserved. + * Author: Stefan Richter + * + * based on: c5471/c5471_lowputc.S + * Copyright (C) 2007, 2008 Gregory Nutt. All rights reserved. + * Author: Gregory Nutt + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * 3. Neither the name NuttX nor the names of its contributors may be + * used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + **************************************************************************/ + +/************************************************************************** + * Included Files + **************************************************************************/ + +#include + +#include "chip.h" +#include "up_arch.h" +#include "up_internal.h" + +/************************************************************************** + * Private Definitions + **************************************************************************/ + +/************************************************************************** + * Private Types + **************************************************************************/ + +/************************************************************************** + * Private Function Prototypes + **************************************************************************/ + +/************************************************************************** + * Global Variables + **************************************************************************/ + +/************************************************************************** + * Private Variables + **************************************************************************/ + +/************************************************************************** + * Private Functions + **************************************************************************/ + +/************************************************************************** + * Public Functions + **************************************************************************/ + +/************************************************************************** + * Name: up_lowputc + **************************************************************************/ + +/* This assembly language version has the advantage that it can does not + * require a C stack and uses only r0-r1. Hence it can be used during + * early boot phases. + */ + + .text + .global up_putc + .type up_putc, function +up_putc: + .global up_lowputc + .type up_lowputc, function +up_lowputc: + /* On entry, r0 holds the character to be printed */ + +#ifdef CONFIG_SERIAL_IRDA_CONSOLE + ldr r2, =UART_IRDA_BASE /* r2=IRDA UART base */ +#else + ldr r2, =UART_MODEM_BASE /* r2=Modem UART base */ +#endif + + /* Poll bit 0 of the UART_SSR register. When the bit + * is clear, the TX FIFO is no longer full + */ + +1: ldrb r1, [r2, #UART_SSR_OFFS] + tst r1, #UART_SSR_TXFULL + bne 1b + + /* Send the character by writing it into the UART_THR + * register. + */ + + strb r0, [r2, #UART_THR_OFFS] + + /* Wait for the tranmsit holding regiser (THR) to be + * emptied. This is detemined when bit 6 of the LSR + * is set. + */ + +2: ldrb r1, [r2, #UART_LSR_OFFS] + tst r1, #0x00000020 + beq 2b + + /* If the character that we just sent was a linefeed, + * then send a carriage return as well. + */ + + teq r0, #'\n' + moveq r0, #'\r' + beq 1b + + /* And return */ + + mov pc, lr + diff --git a/nuttx/arch/arm/src/calypso/chip.h b/nuttx/arch/arm/src/calypso/chip.h new file mode 100644 index 0000000..b837871 --- /dev/null +++ b/nuttx/arch/arm/src/calypso/chip.h @@ -0,0 +1,204 @@ +/**************************************************************************** + * calypso/chip.h + * + * Copyright (C) 2011 Stefan Richter. All rights reserved. + * Author: Stefan Richter + * + * based on: c5471/chip.h + * Copyright (C) 2007 Gregory Nutt. All rights reserved. + * Author: Gregory Nutt + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * 3. Neither the name Gregory Nutt nor the names of its contributors may be + * used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + ****************************************************************************/ + +#ifndef __CALYPSO_CHIP_H +#define __CALYPSO_CHIP_H + +/**************************************************************************** + * Included Files + ****************************************************************************/ + +/**************************************************************************** + * Definitions + ****************************************************************************/ + +/* UARTs ********************************************************************/ + +#define UART_IRDA_BASE 0xffff5000 +#define UART_MODEM_BASE 0xffff5800 +#define UARTn_IO_RANGE 0x00000800 + +/* Common UART Registers. Expressed as offsets from the BASE address */ + +#define UART_RHR_OFFS 0x00000000 /* Rcv Holding Register */ +#define UART_THR_OFFS 0x00000000 /* Xmit Holding Register */ +#define UART_FCR_OFFS 0x00000008 /* FIFO Control Register */ +#define UART_RFCR_OFFS 0x00000008 /* Rcv FIFO Control Register */ +#define UART_TFCR_OFFS 0x00000008 /* Xmit FIFO Control Register */ +#define UART_SCR_OFFS 0x0000000c /* Status Control Register */ +#define UART_LCR_OFFS 0x00000010 /* Line Control Register */ +#define UART_LSR_OFFS 0x00000005 /* Line Status Register */ +#define UART_SSR_OFFS 0x00000011 /* Supplementary Status Register */ +#define UART_MCR_OFFS 0x0000001c /* Modem Control Register */ +#define UART_MSR_OFFS 0x00000020 /* Modem Status Register */ +#define UART_IER_OFFS 0x00000024 /* Interrupt Enable Register */ +#define UART_ISR_OFFS 0x00000028 /* Interrupt Status Register */ +#define UART_EFR_OFFS 0x0000002c /* Enhanced Feature Register */ +#define UART_XON1_OFFS 0x00000030 /* XON1 Character Register */ +#define UART_XON2_OFFS 0x00000034 /* XON2 Character Register */ +#define UART_XOFF1_OFFS 0x00000038 /* XOFF1 Character Register */ +#define UART_XOFF2_OFFS 0x0000003c /* XOFF2 Character Register */ +#define UART_SPR_OFFS 0x00000040 /* Scratch-pad Register */ +#define UART_DIV_115K_OFFS 0x00000044 /* Divisor for baud generation */ +#define UART_DIV_BIT_RATE_OFFS 0x00000048 /* For baud rate generation */ +#define UART_TCR_OFFS 0x0000004c /* Transmission Control Register */ +#define UART_TLR_OFFS 0x00000050 /* Trigger Level Register */ +#define UART_MDR_OFFS 0x00000054 /* Mode Definition Register */ + +/* UART Settings ************************************************************/ + +/* Miscellaneous UART settings. */ + +#define UART_RX_FIFO_NOEMPTY 0x00000001 +#define UART_SSR_TXFULL 0x00000001 +#define UART_LSR_TREF 0x00000020 + +#define UART_XMIT_FIFO_SIZE 64 +#define UART_IRDA_XMIT_FIFO_SIZE 64 + +/* UART_LCR Register */ + /* Bits 31-7: Reserved */ +#define UART_LCR_BOC 0x00000040 /* Bit 6: Break Control */ + /* Bit 5: Parity Type 2 */ +#define UART_LCR_PAREVEN 0x00000010 /* Bit 4: Parity Type 1 */ +#define UART_LCR_PARODD 0x00000000 +#define UART_LCR_PAREN 0x00000008 /* Bit 3: Paity Enable */ +#define UART_LCR_PARDIS 0x00000000 +#define UART_LCR_2STOP 0x00000004 /* Bit 2: Number of stop bits */ +#define UART_LCR_1STOP 0x00000000 +#define UART_LCR_5BITS 0x00000000 /* Bits 0-1: Word-length */ +#define UART_LCR_6BITS 0x00000001 +#define UART_LCR_7BITS 0x00000002 +#define UART_LCR_8BITS 0x00000003 + +#define UART_FCR_FTL 0x00000000 +#define UART_FCR_FIFO_EN 0x00000001 +#define UART_FCR_TX_CLR 0x00000002 +#define UART_FCR_RX_CLR 0x00000004 + +#define UART_IER_RECVINT 0x00000001 +#define UART_IER_XMITINT 0x00000002 +#define UART_IER_LINESTSINT 0x00000004 +#define UART_IER_MODEMSTSINT 0x00000008 /* IrDA UART only */ +#define UART_IER_XOFFINT 0x00000020 +#define UART_IER_RTSINT 0x00000040 /* IrDA UART only */ +#define UART_IER_CTSINT 0x00000080 /* IrDA UART only */ +#define UART_IER_INTMASK 0x000000ff + +#define BAUD_115200 0x00000001 +#define BAUD_57600 0x00000002 +#define BAUD_38400 0x00000003 +#define BAUD_19200 0x00000006 +#define BAUD_9600 0x0000000C +#define BAUD_4800 0x00000018 +#define BAUD_2400 0x00000030 +#define BAUD_1200 0x00000060 + +#define MDR_UART_MODE 0x00000000 /* Both IrDA and Modem UARTs */ +#define MDR_SIR_MODE 0x00000001 /* IrDA UART only */ +#define MDR_AUTOBAUDING_MODE 0x00000002 /* Modem UART only */ +#define MDR_RESET_MODE 0x00000007 /* Both IrDA and Modem UARTs */ + +/* SPI **********************************************************************/ + +#define MAX_SPI 3 + +#define SPI_REGISTER_BASE 0xffff2000 + +/* ARMIO ********************************************************************/ +/* Timers / Watchdog ********************************************************/ + +#define C5471_TIMER0_CTRL 0xffff2a00 +#define C5471_TIMER0_CNT 0xffff2a04 +#define C5471_TIMER1_CTRL 0xffff2b00 +#define C5471_TIMER1_CNT 0xffff2b04 +#define C5471_TIMER2_CTRL 0xffff2c00 +#define C5471_TIMER2_CNT 0xffff2c04 + +/* Interrupts ***************************************************************/ + +#define HAVE_SRC_IRQ_BIN_REG 0 + +#define INT_FIRST_IO 0xffff2d00 +#define INT_IO_RANGE 0x5C + +#define IT_REG 0xffff2d00 +#define MASK_IT_REG 0xffff2d04 +#define SRC_IRQ_REG 0xffff2d08 +#define SRC_FIQ_REG 0xffff2d0c +#define SRC_IRQ_BIN_REG 0xffff2d10 +#define INT_CTRL_REG 0xffff2d18 + +#define ILR_IRQ0_REG 0xffff2d1C /* 0-Timer 0 */ +#define ILR_IRQ1_REG 0xffff2d20 /* 1-Timer 1 */ +#define ILR_IRQ2_REG 0xffff2d24 /* 2-Timer 2 */ +#define ILR_IRQ3_REG 0xffff2d28 /* 3-GPIO0 */ +#define ILR_IRQ4_REG 0xffff2d2c /* 4-Ethernet */ +#define ILR_IRQ5_REG 0xffff2d30 /* 5-KBGPIO[7:0] */ +#define ILR_IRQ6_REG 0xffff2d34 /* 6-Uart serial */ +#define ILR_IRQ7_REG 0xffff2d38 /* 7-Uart IRDA */ +#define ILR_IRQ8_REG 0xffff2d3c /* 8-KBGPIO[15:8] */ +#define ILR_IRQ9_REG 0xffff2d40 /* 9-GPIO3 */ +#define ILR_IRQ10_REG 0xffff2d44 /* 10-GPIO2 */ +#define ILR_IRQ11_REG 0xffff2d48 /* 11-I2C */ +#define ILR_IRQ12_REG 0xffff2d4c /* 12-GPIO1 */ +#define ILR_IRQ13_REG 0xffff2d50 /* 13-SPI */ +#define ILR_IRQ14_REG 0xffff2d54 /* 14-GPIO[19:4] */ +#define ILR_IRQ15_REG 0xffff2d58 /* 15-API */ + +/* CLKM *********************************************************************/ + +#define CLKM 0xffff2f00 +#define CLKM_CTL_RST 0xffff2f10 +#define CLKM_RESET 0xffff2f18 + +#define CLKM_RESET_EIM 0x00000008 +#define CLKM_EIM_CLK_STOP 0x00000010 +#define CLKM_CTL_RST_LEAD_RESET 0x00000000 +#define CLKM_CTL_RST_EXT_RESET 0x00000002 + +/**************************************************************************** + * Inline Functions + ****************************************************************************/ + +/**************************************************************************** + * Public Function Prototypes + ****************************************************************************/ + +#endif /* __CALYPSO_CHIP_H */ diff --git a/nuttx/configs/compal_e99/include/board.h b/nuttx/configs/compal_e99/include/board.h new file mode 100644 index 0000000..1a1a743 --- /dev/null +++ b/nuttx/configs/compal_e99/include/board.h @@ -0,0 +1,6 @@ +/************************************************************************ + * arch/board.h + * + * Supposed to be empty + * + ************************************************************************/ diff --git a/nuttx/configs/compal_e99/ld.script b/nuttx/configs/compal_e99/ld.script new file mode 100644 index 0000000..07f1ab0 --- /dev/null +++ b/nuttx/configs/compal_e99/ld.script @@ -0,0 +1,126 @@ +/* + * Linker script for running from internal SRAM on Compal phones + * + * This script is tailored specifically to the requirements imposed + * on us by the Compal bootloader. + * + */ + +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(__start) +MEMORY +{ + /* compal-loaded binary: our text, initialized data */ + LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00010000 + /* compal-loaded binary: our unitialized data, stacks, heap */ + IRAM (rw) : ORIGIN = 0x00810000, LENGTH = 0x00010000 +} +SECTIONS +{ + . = 0x800000; + + /* romloader data section, contains passthru interrupt vectors */ + .compal.loader (NOLOAD) : { . = 0x100; } > LRAM + + /* image signature (prepended by osmocon according to phone type) */ + .compal.header (NOLOAD) : { . = 4; } > LRAM + + /* initialization code */ + . = ALIGN(4); + .text.start : { + PROVIDE(__start = .); + KEEP(*(.text.start)) + *(.text.start) + } > LRAM + + /* exception vectors from 0x80001c to 0x800034 */ + .text.exceptions 0x80001c : AT (LOADADDR(.text.start) + SIZEOF(.text.start)) { + KEEP(*(.text.exceptions)) + * (.text.exceptions) + . = ALIGN(4); + } > LRAM + PROVIDE(_exceptions = LOADADDR(.text.exceptions)); + + /* code */ + . = ALIGN(4); + .text (LOADADDR(.text.exceptions) + SIZEOF(.text.exceptions)) : + AT (LOADADDR(.text.exceptions) + SIZEOF(.text.exceptions)) { + /* regular code */ + *(.text*) + /* always-in-ram code */ + *(.ramtext*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + . = ALIGN(4); + } > LRAM + PROVIDE(_text_start = LOADADDR(.text)); + PROVIDE(_text_end = LOADADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > LRAM + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > LRAM + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + . = ALIGN(4); + .rodata : { + *(.rodata*) + } > LRAM + PROVIDE(_rodata_start = LOADADDR(.rodata)); + PROVIDE(_rodata_end = LOADADDR(.rodata) + SIZEOF(.rodata)); + + /* initialized data */ + . = ALIGN(4); + .data : { + *(.data) + } > LRAM + PROVIDE(_data_start = LOADADDR(.data)); + PROVIDE(_data_end = LOADADDR(.data) + SIZEOF(.data)); + + /* pic offset tables */ + . = ALIGN(4); + .got : { + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + } > LRAM + PROVIDE(_got_start = LOADADDR(.got)); + PROVIDE(_got_end = LOADADDR(.got) + SIZEOF(.got)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + __bss_start = .; + _sbss = ABSOLUTE(.); + *(.bss) + _ebss = ABSOLUTE(.); + } > IRAM + . = ALIGN(4); + __bss_end = .; + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} diff --git a/nuttx/configs/compal_e99/ostest/Make.defs b/nuttx/configs/compal_e99/ostest/Make.defs new file mode 100644 index 0000000..06ef3d4 --- /dev/null +++ b/nuttx/configs/compal_e99/ostest/Make.defs @@ -0,0 +1,123 @@ +############################################################################ +# configs/compal_e99/ostest/Make.defs +# +# Copyright (C) 2007, 2008, 2011 Gregory Nutt. All rights reserved. +# Author: Gregory Nutt +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# 3. Neither the name NuttX nor the names of its contributors may be +# used to endorse or promote products derived from this software +# without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS +# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED +# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. +# +############################################################################ + +include ${TOPDIR}/.config + +OSMODIR = $(TOPDIR)/../../osmocom-bb +EXTRA_LIBS = $(OSMODIR)/src/target/firmware/comm/libcomm.a $(OSMODIR)/src/shared/libosmocore/build-target/src/.libs/libosmocore.a $(OSMODIR)/src/target/firmware/comm/libcomm.a + # ^^^ Stupid hack! Why do I have to put it twice??? + +CROSSDEV = arm-elf- +CC = $(CROSSDEV)gcc +CPP = $(CROSSDEV)gcc -E +LD = $(CROSSDEV)ld +AR = $(CROSSDEV)ar rcs +NM = $(CROSSDEV)nm +OBJCOPY = $(CROSSDEV)objcopy +OBJDUMP = $(CROSSDEV)objdump + +ARCHCCVERSION = ${shell $(CC) -v 2>&1 | sed -n '/^gcc version/p' | sed -e 's/^gcc version \([0-9\.]\)/\1/g' -e 's/[-\ ].*//g' -e '1q'} +ARCHCCMAJOR = ${shell echo $(ARCHCCVERSION) | cut -d'.' -f1} + +ifeq ("${CONFIG_DEBUG_SYMBOLS}","y") + ARCHOPTIMIZATION = -g +else + ARCHOPTIMIZATION = -Os -fno-strict-aliasing -fno-strength-reduce \ + -fomit-frame-pointer +endif + +ifeq ($(ARCHCCMAJOR),4) + ARCHCPUFLAGS = -mcpu=arm7tdmi -mfloat-abi=soft -fno-builtin +else + ARCHCPUFLAGS = -mapcs-32 -mcpu=arm7tdmi -msoft-float -fno-builtin +endif +ARCHPICFLAGS = -fpic -msingle-pic-base -mpic-register=r10 +ARCHWARNINGS = -Wall -Wstrict-prototypes -Wshadow +ARCHDEFINES = +ARCHINCLUDES = -I. -I$(OSMODIR)/src/shared/libosmocore/include -isystem $(TOPDIR)/include +ARCHSCRIPT = -T$(TOPDIR)/configs/$(CONFIG_ARCH_BOARD)/ld.script + +CFLAGS = $(ARCHWARNINGS) $(ARCHOPTIMIZATION) \ + $(ARCHCPUFLAGS) $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe +CPICFLAGS = $(ARCHPICFLAGS) $(CFLAGS) +CPPFLAGS = $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) +AFLAGS = $(CFLAGS) -D__ASSEMBLY__ + +NXFLATLDFLAGS1 = -r -d -warn-common +NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) \ + -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld \ + -no-check-sections +LDNXFLATFLAGS = -e main -s 2048 + +OBJEXT = .o +LIBEXT = .a +EXEEXT = + +ifeq ("${CONFIG_DEBUG_SYMBOLS}","y") + LDFLAGS += -g +endif + +define PREPROCESS + @echo "CPP: $1->$2" + @$(CPP) $(CPPFLAGS) $1 -o $2 +endef + +define COMPILE + @echo "CC: $1" + @$(CC) -c $(CFLAGS) $1 -o $2 +endef + +define ASSEMBLE + @echo "AS: $1" + @$(CC) -c $(AFLAGS) $1 -o $2 +endef + +define ARCHIVE + echo "AR: $2"; \ + $(AR) $1 $2 || { echo "$(AR) $1 $2 FAILED!" ; exit 1 ; } +endef + +define CLEAN + @rm -f *.o *.a +endef + +MKDEP = $(TOPDIR)/tools/mkdeps.sh + +HOSTCC = gcc +HOSTINCLUDES = -I. +HOSTCFLAGS = -Wall -wstrict-prototypes -Wshadow -g -pipe +HOSTLDFLAGS = + + diff --git a/nuttx/configs/compal_e99/ostest/appconfig b/nuttx/configs/compal_e99/ostest/appconfig new file mode 100644 index 0000000..97e30c0 --- /dev/null +++ b/nuttx/configs/compal_e99/ostest/appconfig @@ -0,0 +1,39 @@ +############################################################################ +# configs/c5471evm/ostest/appconfig +# +# Copyright (C) 2011 Gregory Nutt. All rights reserved. +# Author: Gregory Nutt +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# 3. Neither the name NuttX nor the names of its contributors may be +# used to endorse or promote products derived from this software +# without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS +# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED +# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. +# +############################################################################ + +# Path to example in apps/examples containing the user_start entry point + +CONFIGURED_APPS += examples/ostest + diff --git a/nuttx/configs/compal_e99/ostest/defconfig b/nuttx/configs/compal_e99/ostest/defconfig new file mode 100644 index 0000000..7cb55e2 --- /dev/null +++ b/nuttx/configs/compal_e99/ostest/defconfig @@ -0,0 +1,414 @@ +############################################################################ +# configs/compal_e99/ostest/defconfig +# +# Copyright (C) 2007-2011 Gregory Nutt. All rights reserved. +# Author: Gregory Nutt +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# 3. Neither the name NuttX nor the names of its contributors may be +# used to endorse or promote products derived from this software +# without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS +# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED +# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. +# +############################################################################ +# +# architecture selection +# +# CONFIG_ARCH - identifies the arch subdirectory and, hence, the +# processor architecture. +# CONFIG_ARCH_family - for use in C code. This identifies the +# particular chip family that the architecture is implemented +# in. +# CONFIG_ARCH_architecture - for use in C code. This identifies the +# specific architecture within the chip familyl. +# CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory +# CONFIG_ARCH_CHIP_name - For use in C code +# CONFIG_ARCH_BOARD - identifies the configs subdirectory and, hence, +# the board that supports the particular chip or SoC. +# CONFIG_ARCH_BOARD_name - for use in C code +# CONFIG_BOARD_LOOPSPERMSEC - for delay loops +# CONFIG_ENDIAN_BIG - define if big endian (default is little endian) +# CONFIG_ROM_VECTORS - unique to c5471 +# CONFIG_DRAM_END - the size of installed DRAM. +# Unique to c5471 +# CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to c5471. +# CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt +# stack. If defined, this symbol is the size of the interrupt +# stack in bytes. If not defined, the user task stacks will be +# used during interrupt handling. +# CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions +# +CONFIG_ARCH=arm +CONFIG_ARCH_ARM=y +CONFIG_ARCH_ARM7TDMI=y +CONFIG_ARCH_CHIP=calypso +CONFIG_ARCH_CHIP_CALYPSO=y +CONFIG_ARCH_BOARD=compal_e99 +CONFIG_ARCH_BOARD_COMPALE99=y +CONFIG_BOARD_LOOPSPERMSEC=1250 +CONFIG_ROM_VECTORS=n +CONFIG_DRAM_END=0x00840000 +CONFIG_ARCH_LEDS=n +CONFIG_ARCH_INTERRUPTSTACK=1024 +CONFIG_ARCH_STACKDUMP=y + +# +# General build options +# +# CONFIG_RRLOAD_BINARY - make the rrload binary format used with +# BSPs from www.ridgerun.com using the tools/mkimage.sh script +# CONFIG_INTELHEX_BINARY - make the Intel HEX binary format +# used with many different loaders using the GNU objcopy program +# Should not be selected if you are not using the GNU toolchain. +# CONFIG_RAW_BINARY - make a raw binary format file used with many +# different loaders using the GNU objcopy program. This option +# should not be selected if you are not using the GNU toolchain. +# CONFIG_HAVE_LIBM - toolchain supports libm.a +# +CONFIG_RRLOAD_BINARY=n +CONFIG_INTELHEX_BINARY=n +CONFIG_RAW_BINARY=y +CONFIG_HAVE_LIBM=n + +# +# General OS setup +# +# CONFIG_APPS_DIR - Identifies the relative path to the directory +# that builds the application to link with NuttX. Default: ../apps +# CONFIG_DEBUG - enables built-in debug options +# CONFIG_DEBUG_VERBOSE - enables verbose debug output +# CONFIG_DEBUG_SYMBOLS - build without optimization and with +# debug symbols (needed for use with a debugger). +# CONFIG_MM_REGIONS - If the architecture includes multiple +# regions of memory to allocate from, this specifies the +# number of memory regions that the memory manager must +# handle and enables the API mm_addregion(start, end); +# CONFIG_ARCH_LOWPUTC - architecture supports low-level, boot +# time console output +# CONFIG_TICKS_PER_MSEC - The default system timer is 100Hz +# or TICKS_PER_MSEC=10. This setting may be defined to +# inform NuttX that the processor hardware is providing +# system timer interrupts at some interrupt interval other +# than 10 msec. +# CONFIG_RR_INTERVAL - The round robin timeslice will be set +# this number of milliseconds; Round robin scheduling can +# be disabled by setting this value to zero. +# CONFIG_SCHED_INSTRUMENTATION - enables instrumentation in +# scheduler to monitor system performance +# CONFIG_TASK_NAME_SIZE - Spcifies that maximum size of a +# task name to save in the TCB. Useful if scheduler +# instrumentation is selected. Set to zero to disable. +# CONFIG_START_YEAR, CONFIG_START_MONTH, CONFIG_START_DAY - +# Used to initialize the internal time logic. +# CONFIG_JULIAN_TIME - Enables Julian time conversions +# CONFIG_DEV_CONSOLE - Set if architecture-specific logic +# provides /dev/console. Enables stdout, stderr, stdin. +# CONFIG_DEV_LOWCONSOLE - Use the simple, low-level serial console +# driver (minimul support) +# CONFIG_MUTEX_TYPES: Set to enable support for recursive and +# errorcheck mutexes. Enables pthread_mutexattr_settype(). +# CONFIG_PRIORITY_INHERITANCE : Set to enable support for priority +# inheritance on mutexes and semaphores. +# CONFIG_SEM_PREALLOCHOLDERS: This setting is only used if priority +# inheritance is enabled. It defines the maximum number of +# different threads (minus one) that can take counts on a +# semaphore with priority inheritance support. This may be +# set to zero if priority inheritance is disabled OR if you +# are only using semaphores as mutexes (only one holder) OR +# if no more than two threads participate using a counting +# semaphore. +# CONFIG_SEM_NNESTPRIO. If priority inheritance is enabled, +# then this setting is the maximum number of higher priority +# threads (minus 1) than can be waiting for another thread +# to release a count on a semaphore. This value may be set +# to zero if no more than one thread is expected to wait for +# a semaphore. +# CONFIG_FDCLONE_DISABLE. Disable cloning of all file descriptors +# by task_create() when a new task is started. If set, all +# files/drivers will appear to be closed in the new task. +# CONFIG_FDCLONE_STDIO. Disable cloning of all but the first +# three file descriptors (stdin, stdout, stderr) by task_create() +# when a new task is started. If set, all files/drivers will +# appear to be closed in the new task except for stdin, stdout, +# and stderr. +# CONFIG_SDCLONE_DISABLE. Disable cloning of all socket +# desciptors by task_create() when a new task is started. If +# set, all sockets will appear to be closed in the new task. +# CONFIG_NXFLAT. Enable support for the NXFLAT binary format. +# This format will support execution of NuttX binaries located +# in a ROMFS filesystem (see examples/nxflat). +# +#CONFIG_APPS_DIR= +CONFIG_DEBUG=n +CONFIG_DEBUG_VERBOSE=n +CONFIG_DEBUG_SYMBOLS=n +CONFIG_MM_REGIONS=2 +CONFIG_ARCH_LOWPUTC=y +CONFIG_RR_INTERVAL=200 +CONFIG_SCHED_INSTRUMENTATION=n +CONFIG_TASK_NAME_SIZE=0 +CONFIG_START_YEAR=2007 +CONFIG_START_MONTH=2 +CONFIG_START_DAY=13 +CONFIG_JULIAN_TIME=n +CONFIG_DEV_CONSOLE=n +CONFIG_DEV_LOWCONSOLE=n +CONFIG_MUTEX_TYPES=n +CONFIG_PRIORITY_INHERITANCE=n +CONFIG_SEM_PREALLOCHOLDERS=0 +CONFIG_SEM_NNESTPRIO=0 +CONFIG_FDCLONE_DISABLE=n +CONFIG_FDCLONE_STDIO=n +CONFIG_SDCLONE_DISABLE=y +CONFIG_NXFLAT=n + +# +# The following can be used to disable categories of +# APIs supported by the OS. If the compiler supports +# weak functions, then it should not be necessary to +# disable functions unless you want to restrict usage +# of those APIs. +# +# There are certain dependency relationships in these +# features. +# +# o mq_notify logic depends on signals to awaken tasks +# waiting for queues to become full or empty. +# o pthread_condtimedwait() depends on signals to wake +# up waiting tasks. +# +CONFIG_DISABLE_CLOCK=n +CONFIG_DISABLE_POSIX_TIMERS=n +CONFIG_DISABLE_PTHREAD=n +CONFIG_DISABLE_SIGNALS=n +CONFIG_DISABLE_MQUEUE=y +CONFIG_DISABLE_MOUNTPOINT=y +CONFIG_DISABLE_ENVIRON=n +CONFIG_DISABLE_POLL=y + +# +# Misc libc settings +# +# CONFIG_NOPRINTF_FIELDWIDTH - sprintf-related logic is a +# little smaller if we do not support fieldwidthes +# +CONFIG_NOPRINTF_FIELDWIDTH=n + +# +# Allow for architecture optimized implementations +# +# The architecture can provide optimized versions of the +# following to improve sysem performance +# +CONFIG_ARCH_MEMCPY=n +CONFIG_ARCH_MEMCMP=n +CONFIG_ARCH_MEMMOVE=n +CONFIG_ARCH_MEMSET=n +CONFIG_ARCH_STRCMP=n +CONFIG_ARCH_STRCPY=n +CONFIG_ARCH_STRNCPY=n +CONFIG_ARCH_STRLEN=n +CONFIG_ARCH_STRNLEN=n +CONFIG_ARCH_BZERO=n + +# +# Sizes of configurable things (0 disables) +# +# CONFIG_MAX_TASKS - The maximum number of simultaneously +# active tasks. This value must be a power of two. +# CONFIG_MAX_TASK_ARGS - This controls the maximum number of +# of parameters that a task may receive (i.e., maxmum value +# of 'argc') +# CONFIG_NPTHREAD_KEYS - The number of items of thread- +# specific data that can be retained +# CONFIG_NFILE_DESCRIPTORS - The maximum number of file +# descriptors (one for each open) +# CONFIG_NFILE_STREAMS - The maximum number of streams that +# can be fopen'ed +# CONFIG_NAME_MAX - The maximum size of a file name. +# CONFIG_STDIO_BUFFER_SIZE - Size of the buffer to allocate +# on fopen. (Only if CONFIG_NFILE_STREAMS > 0) +# CONFIG_NUNGET_CHARS - Number of characters that can be +# buffered by ungetc() (Only if CONFIG_NFILE_STREAMS > 0) +# CONFIG_PREALLOC_MQ_MSGS - The number of pre-allocated message +# structures. The system manages a pool of preallocated +# message structures to minimize dynamic allocations +# CONFIG_MQ_MAXMSGSIZE - Message structures are allocated with +# a fixed payload size given by this settin (does not include +# other message structure overhead. +# CONFIG_MAX_WDOGPARMS - Maximum number of parameters that +# can be passed to a watchdog handler +# CONFIG_PREALLOC_WDOGS - The number of pre-allocated watchdog +# structures. The system manages a pool of preallocated +# watchdog structures to minimize dynamic allocations +# CONFIG_PREALLOC_TIMERS - The number of pre-allocated POSIX +# timer structures. The system manages a pool of preallocated +# timer structures to minimize dynamic allocations. Set to +# zero for all dynamic allocations. +# +CONFIG_MAX_TASKS=64 +CONFIG_MAX_TASK_ARGS=4 +CONFIG_NPTHREAD_KEYS=4 +CONFIG_NFILE_DESCRIPTORS=32 +CONFIG_NFILE_STREAMS=16 +CONFIG_NAME_MAX=32 +CONFIG_STDIO_BUFFER_SIZE=256 +CONFIG_NUNGET_CHARS=2 +CONFIG_PREALLOC_MQ_MSGS=32 +CONFIG_MQ_MAXMSGSIZE=32 +CONFIG_MAX_WDOGPARMS=4 +CONFIG_PREALLOC_WDOGS=32 +CONFIG_PREALLOC_TIMERS=8 + +# +# TCP/IP and UDP support via uIP +# CONFIG_NET - Enable or disable all network features +# CONFIG_NET_IPv6 - Build in support for IPv6 +# CONFIG_NSOCKET_DESCRIPTORS - Maximum number of socket descriptors per task/thread. +# CONFIG_NET_SOCKOPTS - Enable or disable support for socket options +# CONFIG_NET_BUFSIZE - uIP buffer size +# CONFIG_NET_TCP - TCP support on or off +# CONFIG_NET_TCP_CONNS - Maximum number of TCP connections (all tasks) +# CONFIG_NET_TCP_READAHEAD_BUFSIZE - Size of TCP read-ahead buffers +# CONFIG_NET_NTCP_READAHEAD_BUFFERS - Number of TCP read-ahead buffers (may be zero) +# CONFIG_NET_TCPBACKLOG - Incoming connections pend in a backlog until +# accept() is called. The size of the backlog is selected when listen() is called. +# CONFIG_NET_MAX_LISTENPORTS - Maximum number of listening TCP ports (all tasks) +# CONFIG_NET_UDP - UDP support on or off +# CONFIG_NET_UDP_CHECKSUMS - UDP checksums on or off +# CONFIG_NET_UDP_CONNS - The maximum amount of concurrent UDP connections +# CONFIG_NET_ICMP - ICMP ping response support on or off +# CONFIG_NET_ICMP_PING - ICMP ping request support on or off +# CONFIG_NET_PINGADDRCONF - Use "ping" packet for setting IP address +# CONFIG_NET_STATISTICS - uIP statistics on or off +# CONFIG_NET_RECEIVE_WINDOW - The size of the advertised receiver's window +# CONFIG_NET_ARPTAB_SIZE - The size of the ARP table +# CONFIG_NET_BROADCAST - Broadcast support +# CONFIG_NET_FWCACHE_SIZE - number of packets to remember when looking for duplicates +# +CONFIG_NET=n +CONFIG_NET_IPv6=n +CONFIG_NSOCKET_DESCRIPTORS=0 +CONFIG_NET_SOCKOPTS=y +CONFIG_NET_BUFSIZE=420 +CONFIG_NET_TCP=n +CONFIG_NET_TCP_CONNS=40 +CONFIG_NET_NTCP_READAHEAD_BUFFERS=8 +CONFIG_NET_TCPBACKLOG=n +CONFIG_NET_MAX_LISTENPORTS=40 +CONFIG_NET_UDP=n +CONFIG_NET_UDP_CHECKSUMS=y +#CONFIG_NET_UDP_CONNS=10 +CONFIG_NET_ICMP=n +CONFIG_NET_ICMP_PING=n +#CONFIG_NET_PINGADDRCONF=0 +CONFIG_NET_STATISTICS=y +#CONFIG_NET_RECEIVE_WINDOW= +#CONFIG_NET_ARPTAB_SIZE=8 +CONFIG_NET_BROADCAST=n +#CONFIG_NET_FWCACHE_SIZE=2 + +# +# UIP Network Utilities +# CONFIG_NET_DHCP_LIGHT - Reduces size of DHCP +# CONFIG_NET_RESOLV_ENTRIES - Number of resolver entries +CONFIG_NET_DHCP_LIGHT=n +CONFIG_NET_RESOLV_ENTRIES=4 + +# +# Settings for examples/uip +CONFIG_EXAMPLE_UIP_NOMAC=y +CONFIG_EXAMPLE_UIP_IPADDR=(10<<24|0<<16|0<<8|2) +CONFIG_EXAMPLE_UIP_DRIPADDR=(10<<24|0<<16|0<<8|1) +CONFIG_EXAMPLE_UIP_NETMASK=(255<<24|255<<16|255<<8|0) +CONFIG_EXAMPLE_UIP_DHCPC=n + +# +# Settings for examples/nettest +CONFIG_EXAMPLE_NETTEST_SERVER=n +CONFIG_EXAMPLE_NETTEST_PERFORMANCE=n +CONFIG_EXAMPLE_NETTEST_NOMAC=y +CONFIG_EXAMPLE_NETTEST_IPADDR=(10<<24|0<<16|0<<8|2) +CONFIG_EXAMPLE_NETTEST_DRIPADDR=(10<<24|0<<16|0<<8|1) +CONFIG_EXAMPLE_NETTEST_NETMASK=(255<<24|255<<16|255<<8|0) +CONFIG_EXAMPLE_NETTEST_CLIENTIP=(10<<24|0<<16|0<<8|1) + +# +# Settings for examples/nsh +CONFIG_NSH_CONSOLE=y +CONFIG_NSH_TELNET=n +CONFIG_NSH_IOBUFFER_SIZE=512 +CONFIG_NSH_CMD_SIZE=40 +CONFIG_NSH_STACKSIZE=4096 +CONFIG_NSH_DHCPC=n +CONFIG_NSH_NOMAC=y +CONFIG_NSH_IPADDR=(10<<24|0<<16|0<<8|2) +CONFIG_NSH_DRIPADDR=(10<<24|0<<16|0<<8|1) +CONFIG_NSH_NETMASK=(255<<24|255<<16|255<<8|0) + +# +# Settings for examples/wget +# CONFIG_EXAMPLE_WGET_URL - The URL of the file to get +# CONFIG_EXAMPLE_WGET_NOMAC - (May be defined to use software assigned MAC) +# CONFIG_EXAMPLE_WGET_IPADDR - Target IP address +# CONFIG_EXAMPLE_WGET_DRIPADDR - Default router IP addess +# CONFIG_EXAMPLE_WGET_NETMASK - Network mask +CONFIG_EXAMPLE_WGET_URL="http://www.nuttx.org/index.html" +CONFIG_EXAMPLE_WGET_NOMAC=y +CONFIG_EXAMPLE_WGET_IPADDR=(10L<<24|0L<<16|0L<<8|2L) +CONFIG_EXAMPLE_WGET_DRIPADDR=(10L<<24|0L<<16|0L<<8|1L) +CONFIG_EXAMPLE_WGET_NETMASK=(255L<<24|255L<<16|255L<<8|0L) + +# +# Stack and heap information +# +# CONFIG_BOOT_RUNFROMFLASH - Some configurations support XIP +# operation from FLASH but must copy initialized .data sections to RAM. +# CONFIG_BOOT_COPYTORAM - Some configurations boot in FLASH +# but copy themselves entirely into RAM for better performance. +# CONFIG_CUSTOM_STACK - The up_ implementation will handle +# all stack operations outside of the nuttx model. +# CONFIG_STACK_POINTER - The initial stack pointer (arm7tdmi only) +# CONFIG_IDLETHREAD_STACKSIZE - The size of the initial stack. +# This is the thread that (1) performs the inital boot of the system up +# to the point where user_start() is spawned, and (2) there after is the +# IDLE thread that executes only when there is no other thread ready to +# run. +# CONFIG_USERMAIN_STACKSIZE - The size of the stack to allocate +# for the main user thread that begins at the user_start() entry point. +# CONFIG_PTHREAD_STACK_MIN - Minimum pthread stack size +# CONFIG_PTHREAD_STACK_DEFAULT - Default pthread stack size +# CONFIG_HEAP_BASE - The beginning of the heap +# CONFIG_HEAP_SIZE - The size of the heap +# +CONFIG_BOOT_RUNFROMFLASH=n +CONFIG_BOOT_COPYTORAM=n +CONFIG_CUSTOM_STACK=n +CONFIG_STACK_POINTER= +CONFIG_IDLETHREAD_STACKSIZE=4096 +CONFIG_USERMAIN_STACKSIZE=4096 +CONFIG_PTHREAD_STACK_MIN=256 +CONFIG_PTHREAD_STACK_DEFAULT=4096 +CONFIG_HEAP_BASE= +CONFIG_HEAP_SIZE= diff --git a/nuttx/configs/compal_e99/ostest/setenv.sh b/nuttx/configs/compal_e99/ostest/setenv.sh new file mode 100755 index 0000000..dc2c643 --- /dev/null +++ b/nuttx/configs/compal_e99/ostest/setenv.sh @@ -0,0 +1,46 @@ +#!/bin/bash +# c5471evm/ostest/setenv.sh +# +# Copyright (C) 2007, 2008, 2011 Gregory Nutt. All rights reserved. +# Author: Gregory Nutt +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# 3. Neither the name NuttX nor the names of its contributors may be +# used to endorse or promote products derived from this software +# without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS +# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED +# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. +# + +if [ "$(basename $0)" = "setenv.sh" ] ; then + echo "You must source this script, not run it!" 1>&2 + exit 1 +fi + +if [ -z ${PATH_ORIG} ]; then export PATH_ORIG=${PATH}; fi + +WD=`pwd` +export BUILDROOT_BIN=${WD}/../buildroot/build_arm_nofpu/staging_dir/bin +export PATH=${BUILDROOT_BIN}:/sbin:/usr/sbin:${PATH_ORIG} + +echo "PATH : ${PATH}" diff --git a/nuttx/configs/compal_e99/src/Makefile b/nuttx/configs/compal_e99/src/Makefile new file mode 100644 index 0000000..2160ea3 --- /dev/null +++ b/nuttx/configs/compal_e99/src/Makefile @@ -0,0 +1,80 @@ +############################################################################ +# configs/compal_e99/src/Makefile +# +# Copyright (C) 2007, 2008 Gregory Nutt. All rights reserved. +# Author: Gregory Nutt +# +# Copyright (C) 2011 Stefan Richter. All rights reserved. +# Author: Stefan Richter +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# 1. Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# 2. Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# 3. Neither the name NuttX nor the names of its contributors may be +# used to endorse or promote products derived from this software +# without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS +# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE +# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS +# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED +# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN +# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. +# +############################################################################ + +-include $(TOPDIR)/Make.defs + +CFLAGS += -I$(TOPDIR)/sched + +ASRCS = +AOBJS = $(ASRCS:.S=$(OBJEXT)) +CSRCS = dummy.c +COBJS = $(CSRCS:.c=$(OBJEXT)) + +SRCS = $(ASRCS) $(CSRCS) +OBJS = $(AOBJS) $(COBJS) + +ARCH_SRCDIR = $(TOPDIR)/arch/$(CONFIG_ARCH)/src +CFLAGS += -I$(ARCH_SRCDIR)/chip -I$(ARCH_SRCDIR)/common -I$(ARCH_SRCDIR)/arm + +all: libboard$(LIBEXT) + +$(AOBJS): %$(OBJEXT): %.S + $(call ASSEMBLE, $<, $@) + +$(COBJS) $(LINKOBJS): %$(OBJEXT): %.c + $(call COMPILE, $<, $@) + +libboard$(LIBEXT): $(OBJS) + @( for obj in $(OBJS) ; do \ + $(call ARCHIVE, $@, $${obj}); \ + done ; ) + +.depend: Makefile $(SRCS) + @$(MKDEP) $(CC) -- $(CFLAGS) -- $(SRCS) >Make.dep + @touch $@ + +depend: .depend + +clean: + @rm -f libboard$(LIBEXT) *~ .*.swp + $(call CLEAN) + +distclean: clean + @rm -f Make.dep .depend + +-include Make.dep diff --git a/nuttx/configs/compal_e99/src/dummy.c b/nuttx/configs/compal_e99/src/dummy.c new file mode 100644 index 0000000..69853a1 --- /dev/null +++ b/nuttx/configs/compal_e99/src/dummy.c @@ -0,0 +1 @@ +/* no libboard.a otherwise */ -- 1.7.1 From ichgeh at l--putt.de Tue May 24 21:05:32 2011 From: ichgeh at l--putt.de (l--putt) Date: Tue, 24 May 2011 23:05:32 +0200 Subject: [PATCH 2/4] Initial support for Nuttx on TI Calypso platform Message-ID: <4DDC1D9C.5020103@l--putt.de> From ichgeh at l--putt.de Tue May 24 19:13:49 2011 From: ichgeh at l--putt.de (Stefan Richter) Date: Tue, 24 May 2011 21:13:49 +0200 Subject: [PATCH 2/4] Initial support for Nuttx on TI Calypso platform: Import clock and timer related files Osmocom Modify timer.c to Nuttx API Message-ID: --- nuttx/arch/arm/include/calypso/clock.h | 67 +++++++++ nuttx/arch/arm/include/calypso/timer.h | 25 ++++ nuttx/arch/arm/src/calypso/calypso_timer.c | 205 ++++++++++++++++++++++++++++ nuttx/arch/arm/src/calypso/clock.c | 202 +++++++++++++++++++++++++++ 4 files changed, 499 insertions(+), 0 deletions(-) create mode 100644 nuttx/arch/arm/include/calypso/clock.h create mode 100644 nuttx/arch/arm/include/calypso/timer.h create mode 100644 nuttx/arch/arm/src/calypso/calypso_timer.c create mode 100644 nuttx/arch/arm/src/calypso/clock.c diff --git a/nuttx/arch/arm/include/calypso/clock.h b/nuttx/arch/arm/include/calypso/clock.h new file mode 100644 index 0000000..abcfde1 --- /dev/null +++ b/nuttx/arch/arm/include/calypso/clock.h @@ -0,0 +1,67 @@ +#ifndef _CALYPSO_CLK_H +#define _CALYPSO_CLK_H + +#include + +#define CALYPSO_PLL26_52_MHZ ((2 << 8) | 0) +#define CALYPSO_PLL26_86_7_MHZ ((10 << 8) | 2) +#define CALYPSO_PLL26_87_MHZ ((3 << 8) | 0) +#define CALYPSO_PLL13_104_MHZ ((8 << 8) | 0) + +enum mclk_div { + _ARM_MCLK_DIV_1 = 0, + ARM_MCLK_DIV_1 = 1, + ARM_MCLK_DIV_2 = 2, + ARM_MCLK_DIV_3 = 3, + ARM_MCLK_DIV_4 = 4, + ARM_MCLK_DIV_5 = 5, + ARM_MCLK_DIV_6 = 6, + ARM_MCLK_DIV_7 = 7, + ARM_MCLK_DIV_1_5 = 0x80 | 1, + ARM_MCLK_DIV_2_5 = 0x80 | 2, +}; + +void calypso_clock_set(uint8_t vtcxo_div2, uint16_t inp, enum mclk_div mclk_div); +void calypso_pll_set(uint16_t inp); +void calypso_clk_dump(void); + +/* CNTL_RST */ +enum calypso_rst { + RESET_DSP = (1 << 1), + RESET_EXT = (1 << 2), + RESET_WDOG = (1 << 3), +}; + +void calypso_reset_set(enum calypso_rst calypso_rst, int active); +int calypso_reset_get(enum calypso_rst); + +enum calypso_bank { + CALYPSO_nCS0 = 0, + CALYPSO_nCS1 = 2, + CALYPSO_nCS2 = 4, + CALYPSO_nCS3 = 6, + CALYPSO_nCS7 = 8, + CALYPSO_CS4 = 0xa, + CALYPSO_nCS6 = 0xc, +}; + +enum calypso_mem_width { + CALYPSO_MEM_8bit = 0, + CALYPSO_MEM_16bit = 1, + CALYPSO_MEM_32bit = 2, +}; + +void calypso_mem_cfg(enum calypso_bank bank, uint8_t ws, + enum calypso_mem_width width, int we); + +/* Enable or disable the internal bootrom mapped to 0x0000'0000 */ +void calypso_bootrom(int enable); + +/* Enable or disable the debug unit */ +void calypso_debugunit(int enable); + +/* configure the RHEA bus bridge[s] */ +void calypso_rhea_cfg(uint8_t fac0, uint8_t fac1, uint8_t timeout, + uint8_t ws_h, uint8_t ws_l, uint8_t w_en0, uint8_t w_en1); + +#endif /* _CALYPSO_CLK_H */ diff --git a/nuttx/arch/arm/include/calypso/timer.h b/nuttx/arch/arm/include/calypso/timer.h new file mode 100644 index 0000000..694e4eb --- /dev/null +++ b/nuttx/arch/arm/include/calypso/timer.h @@ -0,0 +1,25 @@ +#ifndef _CAL_TIMER_H +#define _CAL_TIMER_H + +/* Enable or Disable a timer */ +void hwtimer_enable(int num, int on); + +/* Configure pre-scaler and if timer is auto-reload */ +void hwtimer_config(int num, uint8_t pre_scale, int auto_reload); + +/* Load a timer with the given value */ +void hwtimer_load(int num, uint16_t val); + +/* Read the current timer value */ +uint16_t hwtimer_read(int num); + +/* Enable or disable the watchdog */ +void wdog_enable(int on); + +/* Reset cpu using watchdog */ +void wdog_reset(void); + +/* power up the timers */ +void hwtimer_init(void); + +#endif /* _CAL_TIMER_H */ diff --git a/nuttx/arch/arm/src/calypso/calypso_timer.c b/nuttx/arch/arm/src/calypso/calypso_timer.c new file mode 100644 index 0000000..0191c0c --- /dev/null +++ b/nuttx/arch/arm/src/calypso/calypso_timer.c @@ -0,0 +1,205 @@ +/**************************************************************************** + * arch/arm/src/calypso/calypso_timer.c + * Calypso DBB internal Timer Driver + * + * (C) 2010 by Harald Welte + * (C) 2011 by Stefan Richter + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + ****************************************************************************/ + +#include +#include +#include + +#include +#include +#include + + +#define BASE_ADDR_TIMER 0xfffe3800 +#define TIMER2_OFFSET 0x3000 + +#define TIMER_REG(n, m) (((n)-1) ? (BASE_ADDR_TIMER + TIMER2_OFFSET + (m)) : (BASE_ADDR_TIMER + (m))) + +enum timer_reg { + CNTL_TIMER = 0x00, + LOAD_TIMER = 0x02, + READ_TIMER = 0x04, +}; + +enum timer_ctl { + CNTL_START = (1 << 0), + CNTL_AUTO_RELOAD = (1 << 1), + CNTL_CLOCK_ENABLE = (1 << 5), +}; + +/* Regular Timers (1 and 2) */ + +void hwtimer_enable(int num, int on) +{ + uint8_t ctl; + + if (num < 1 || num > 2) { + printf("Unknown timer %u\n", num); + return; + } + + ctl = readb(TIMER_REG(num, CNTL_TIMER)); + if (on) + ctl |= CNTL_START|CNTL_CLOCK_ENABLE; + else + ctl &= ~CNTL_START; + writeb(ctl, TIMER_REG(num, CNTL_TIMER)); +} + +void hwtimer_config(int num, uint8_t pre_scale, int auto_reload) +{ + uint8_t ctl; + + ctl = (pre_scale & 0x7) << 2; + if (auto_reload) + ctl |= CNTL_AUTO_RELOAD; + + writeb(ctl, TIMER_REG(num, CNTL_TIMER)); +} + +void hwtimer_load(int num, uint16_t val) +{ + writew(val, TIMER_REG(num, LOAD_TIMER)); +} + +uint16_t hwtimer_read(int num) +{ + uint8_t ctl = readb(TIMER_REG(num, CNTL_TIMER)); + + /* somehow a read results in an abort */ + if ((ctl & (CNTL_START|CNTL_CLOCK_ENABLE)) != (CNTL_START|CNTL_CLOCK_ENABLE)) + return 0xFFFF; + return readw(TIMER_REG(num, READ_TIMER)); +} + +/************************************************************ + * Watchdog Timer + ************************************************************/ + +#define BASE_ADDR_WDOG 0xfffff800 +#define WDOG_REG(m) (BASE_ADDR_WDOG + m) + +enum wdog_reg { + WD_CNTL_TIMER = CNTL_TIMER, + WD_LOAD_TIMER = LOAD_TIMER, + WD_READ_TIMER = 0x02, + WD_MODE = 0x04, +}; + +enum wdog_ctl { + WD_CTL_START = (1 << 7), + WD_CTL_AUTO_RELOAD = (1 << 8) +}; + +enum wdog_mode { + WD_MODE_DIS_ARM = 0xF5, + WD_MODE_DIS_CONFIRM = 0xA0, + WD_MODE_ENABLE = (1 << 15) +}; + +#define WD_CTL_PRESCALE(value) (((value)&0x07) << 9) + +static void wdog_irq(__unused enum irq_nr nr) +{ + puts("=> WATCHDOG\n"); +} + +void wdog_enable(int on) +{ + if (on) { +#if 0 + irq_config(IRQ_WATCHDOG, 0, 0, 0); + irq_register_handler(IRQ_WATCHDOG, &wdog_irq); + irq_enable(IRQ_WATCHDOG); + writew(WD_MODE_ENABLE, WDOG_REG(WD_MODE)); +#endif + } else { + writew(WD_MODE_DIS_ARM, WDOG_REG(WD_MODE)); + writew(WD_MODE_DIS_CONFIRM, WDOG_REG(WD_MODE)); + } +} + +void wdog_reset(void) +{ +#if 0 + // XXX: this is supposed to reset immediately but does not seem to + writew(0xF5, WDOG_REG(WD_MODE)); + writew(0xFF, WDOG_REG(WD_MODE)); +#else + // enable watchdog + writew(WD_MODE_ENABLE, WDOG_REG(WD_MODE)); + // force expiration + writew(0x0000, WDOG_REG(WD_LOAD_TIMER)); + writew(0x0000, WDOG_REG(WD_LOAD_TIMER)); +#endif +} + +/************************************************************ + * Global Functions + ************************************************************/ + +/************************************************************ + * Function: up_timerisr + * + * Description: + * The timer ISR will perform a variety of services for + * various portions of the systems. + * + ************************************************************/ + +int up_timerisr(int irq, uint32_t *regs) +{ + /* Process timer interrupt */ + + sched_process_timer(); + return 0; +} + +/************************************************************ + * Function: up_timerinit + * + * Description: + * Setup Calypso HW timer 2 to cause system ticks. + * + * This function is called during start-up to initialize + * the timer interrupt. + * + ************************************************************/ + +void up_timerinit(void) +{ + up_disable_irq(IRQ_SYSTIMER); + + /* The timer runs at 13MHz / 32, i.e. 406.25kHz */ + /* 4062 ticks until expiry yields 100Hz interrupt */ + hwtimer_load(2, 4062); + hwtimer_config(2, 0, 1); + hwtimer_enable(2, 1); + + /* Attach and enable the timer interrupt */ + irq_attach(IRQ_SYSTIMER, (xcpt_t)up_timerisr); + up_enable_irq(IRQ_SYSTIMER); +} + diff --git a/nuttx/arch/arm/src/calypso/clock.c b/nuttx/arch/arm/src/calypso/clock.c new file mode 100644 index 0000000..77b4ea5 --- /dev/null +++ b/nuttx/arch/arm/src/calypso/clock.c @@ -0,0 +1,202 @@ +/* Driver for Calypso clock management */ + +/* (C) 2010 by Harald Welte + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include + +#include +#include + +//#define DEBUG +#include + +#include +#include + +#define REG_DPLL 0xffff9800 +#define DPLL_LOCK (1 << 0) +#define DPLL_BREAKLN (1 << 1) +#define DPLL_BYPASS_DIV_SHIFT 2 /* 2 bits */ +#define DPLL_PLL_ENABLE (1 << 4) +#define DPLL_PLL_DIV_SHIFT 5 /* 2 bits */ +#define DPLL_PLL_MULT_SHIFT 7 /* 5 bits */ +#define DPLL_TEST (1 << 12) +#define DPLL_IOB (1 << 13) /* Initialize on break */ +#define DPLL_IAI (1 << 14) /* Initialize after Idle */ + +#define BASE_ADDR_CLKM 0xfffffd00 +#define CLKM_REG(m) (BASE_ADDR_CLKM+(m)) + +enum clkm_reg { + CNTL_ARM_CLK = 0, + CNTL_CLK = 2, + CNTL_RST = 4, + CNTL_ARM_DIV = 8, +}; + +/* CNTL_ARM_CLK */ +#define ARM_CLK_BIG_SLEEP (1 << 0) /* MCU Master Clock enabled? */ +#define ARM_CLK_CLKIN_SEL0 (1 << 1) /* MCU source clock (0 = DPLL output, 1 = VTCXO or CLKIN */ +#define ARM_CLK_CLKIN_SEL (1 << 2) /* 0 = VTCXO or 1 = CLKIN */ +#define ARM_CLK_MCLK_DIV5 (1 << 3) /* enable 1.5 or 2.5 division factor */ +#define ARM_CLK_MCLK_DIV_SHIFT 4 /* 3 bits */ +#define ARM_CLK_DEEP_POWER_SHIFT 8 +#define ARM_CLK_DEEP_SLEEP 12 + +/* CNTL_CLK */ +#define CLK_IRQ_CLK_DIS (1 << 0) /* IRQ clock control (0 always, 1 according ARM_MCLK_EN) */ +#define CLK_BRIDGE_CLK_DIS (1 << 1) +#define CLK_TIMER_CLK_DIS (1 << 2) +#define CLK_DPLL_DIS (1 << 3) /* 0: DPLL is not stopped during SLEEP */ +#define CLK_CLKOUT_EN (1 << 4) /* Enable CLKOUT output pins */ +#define CLK_EN_IDLE3_FLG (1 << 5) /* DSP idle flag control (1 = + * SAM/HOM register forced to HOM when DSP IDLE3) */ +#define CLK_VCLKOUT_DIV2 (1 << 6) /* 1: VCLKOUT-FR is divided by 2 */ +#define CLK_VTCXO_DIV2 (1 << 7) /* 1: VTCXO is dividied by 2 */ + +#define BASE_ADDR_MEMIF 0xfffffb00 +#define MEMIF_REG(x) (BASE_ADDR_MEMIF+(x)) + +enum memif_reg { + API_RHEA_CTL = 0x0e, + EXTRA_CONF = 0x10, +}; + +static void dump_reg16(uint32_t addr, char *name) +{ + printf("%s=0x%04x\n", name, readw(addr)); +} + +void calypso_clk_dump(void) +{ + dump_reg16(REG_DPLL, "REG_DPLL"); + dump_reg16(CLKM_REG(CNTL_ARM_CLK), "CNTL_ARM_CLK"); + dump_reg16(CLKM_REG(CNTL_CLK), "CNTL_CLK"); + dump_reg16(CLKM_REG(CNTL_RST), "CNTL_RST"); + dump_reg16(CLKM_REG(CNTL_ARM_DIV), "CNTL_ARM_DIV"); +} + +void calypso_pll_set(uint16_t inp) +{ + uint8_t mult = inp >> 8; + uint8_t div = inp & 0xff; + uint16_t reg = readw(REG_DPLL); + + reg &= ~0x0fe0; + reg |= (div & 0x3) << DPLL_PLL_DIV_SHIFT; + reg |= (mult & 0x1f) << DPLL_PLL_MULT_SHIFT; + reg |= DPLL_PLL_ENABLE; + + writew(reg, REG_DPLL); +} + +void calypso_reset_set(enum calypso_rst calypso_rst, int active) +{ + uint8_t reg = readb(CLKM_REG(CNTL_RST)); + + if (active) + reg |= calypso_rst; + else + reg &= ~calypso_rst; + + writeb(reg, CLKM_REG(CNTL_RST)); +} + +int calypso_reset_get(enum calypso_rst calypso_rst) +{ + uint8_t reg = readb(CLKM_REG(CNTL_RST)); + + if (reg & calypso_rst) + return 1; + else + return 0; +} + +void calypso_clock_set(uint8_t vtcxo_div2, uint16_t inp, enum mclk_div mclk_div) +{ + uint16_t cntl_clock = readw(CLKM_REG(CNTL_CLK)); + uint16_t cntl_arm_clk = readw(CLKM_REG(CNTL_ARM_CLK)); + + /* First set the vtcxo_div2 */ + cntl_clock &= ~CLK_VCLKOUT_DIV2; + if (vtcxo_div2) + cntl_clock |= CLK_VTCXO_DIV2; + else + cntl_clock &= ~CLK_VTCXO_DIV2; + writew(cntl_clock, CLKM_REG(CNTL_CLK)); + + /* Then configure the MCLK divider */ + cntl_arm_clk &= ~ARM_CLK_CLKIN_SEL0; + if (mclk_div & 0x80) { + mclk_div &= ~0x80; + cntl_arm_clk |= ARM_CLK_MCLK_DIV5; + } else + cntl_arm_clk &= ~ARM_CLK_MCLK_DIV5; + cntl_arm_clk &= ~(0x7 << ARM_CLK_MCLK_DIV_SHIFT); + cntl_arm_clk |= (mclk_div << ARM_CLK_MCLK_DIV_SHIFT); + writew(cntl_arm_clk, CLKM_REG(CNTL_ARM_CLK)); + + /* Then finally set the PLL */ + calypso_pll_set(inp); +} + +void calypso_mem_cfg(enum calypso_bank bank, uint8_t ws, + enum calypso_mem_width width, int we) +{ + writew((ws & 0x1f) | ((width & 3) << 5) | ((we & 1) << 7), + BASE_ADDR_MEMIF + bank); +} + +void calypso_bootrom(int enable) +{ + uint16_t conf = readw(MEMIF_REG(EXTRA_CONF)); + + conf |= (3 << 8); + + if (enable) + conf &= ~(1 << 9); + + writew(conf, MEMIF_REG(EXTRA_CONF)); +} + +void calypso_debugunit(int enable) +{ + uint16_t conf = readw(MEMIF_REG(EXTRA_CONF)); + + if (enable) + conf &= ~(1 << 11); + else + conf |= (1 << 11); + + writew(conf, MEMIF_REG(EXTRA_CONF)); +} + +#define REG_RHEA_CNTL 0xfffff900 +#define REG_API_CNTL 0xfffff902 +#define REG_ARM_RHEA 0xfffff904 + +void calypso_rhea_cfg(uint8_t fac0, uint8_t fac1, uint8_t timeout, + uint8_t ws_h, uint8_t ws_l, uint8_t w_en0, uint8_t w_en1) +{ + writew(fac0 | (fac1 << 4) | (timeout << 8), REG_RHEA_CNTL); + writew(ws_h | (ws_l << 5), REG_API_CNTL); + writew(w_en0 | (w_en1 << 1), REG_ARM_RHEA); +} -- 1.7.1 From ichgeh at l--putt.de Tue May 24 21:05:59 2011 From: ichgeh at l--putt.de (l--putt) Date: Tue, 24 May 2011 23:05:59 +0200 Subject: [PATCH 3/4] Initial support for Nuttx on TI Calypso platform Message-ID: <4DDC1DB7.1090909@l--putt.de> From ichgeh at l--putt.de Tue May 24 19:16:47 2011 From: ichgeh at l--putt.de (Stefan Richter) Date: Tue, 24 May 2011 21:16:47 +0200 Subject: [PATCH 3/4] Initial support for Nuttx on TI Calypso platform: IRQ support for Calypso Main patches Osmocom code to match Nuttx API Message-ID: --- nuttx/arch/arm/include/calypso/irq.h | 67 +++++++ nuttx/arch/arm/src/calypso/calypso_irq.c | 300 ++++++++++++++++++++++++++++++ 2 files changed, 367 insertions(+), 0 deletions(-) create mode 100644 nuttx/arch/arm/include/calypso/irq.h create mode 100644 nuttx/arch/arm/src/calypso/calypso_irq.c diff --git a/nuttx/arch/arm/include/calypso/irq.h b/nuttx/arch/arm/include/calypso/irq.h new file mode 100644 index 0000000..1333a6e --- /dev/null +++ b/nuttx/arch/arm/include/calypso/irq.h @@ -0,0 +1,67 @@ +/**************************************************************************** + * arch/arm/include/calypso/irq.h + * Driver for Calypso IRQ controller + * + * (C) 2010 by Harald Welte + * (C) 2011 by Stefan Richter + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + ****************************************************************************/ + +#ifndef __INCLUDE_NUTTX_IRQ_H +#error "This file should never be included directly! Use " +#endif + +#ifndef _CALYPSO_IRQ_H +#define _CALYPSO_IRQ_H + +#ifndef __ASSEMBLY__ + +enum irq_nr { + IRQ_WATCHDOG = 0, + IRQ_TIMER1 = 1, + IRQ_TIMER2 = 2, + IRQ_TSP_RX = 3, + IRQ_TPU_FRAME = 4, + IRQ_TPU_PAGE = 5, + IRQ_SIMCARD = 6, + IRQ_UART_MODEM = 7, + IRQ_KEYPAD_GPIO = 8, + IRQ_RTC_TIMER = 9, + IRQ_RTC_ALARM_I2C = 10, + IRQ_ULPD_GAUGING = 11, + IRQ_EXTERNAL = 12, + IRQ_SPI = 13, + IRQ_DMA = 14, + IRQ_API = 15, + IRQ_SIM_DETECT = 16, + IRQ_EXTERNAL_FIQ = 17, + IRQ_UART_IRDA = 18, + IRQ_ULPD_GSM_TIMER = 19, + IRQ_GEA = 20, + _NR_IRQS +}; + +#endif /* __ASSEMBLY__ */ + +/* Don't use _NR_IRQS!!! Won't work in preprocessor... */ +#define NR_IRQS 21 + +#define IRQ_SYSTIMER IRQ_TIMER2 + +#endif /* _CALYPSO_IRQ_H */ diff --git a/nuttx/arch/arm/src/calypso/calypso_irq.c b/nuttx/arch/arm/src/calypso/calypso_irq.c new file mode 100644 index 0000000..993e475 --- /dev/null +++ b/nuttx/arch/arm/src/calypso/calypso_irq.c @@ -0,0 +1,300 @@ +/**************************************************************************** + * arch/arm/src/calypso/calypso_irq.c + * Driver for Calypso IRQ controller + * + * (C) 2010 by Harald Welte + * (C) 2011 by Stefan Richter + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + ****************************************************************************/ + +/**************************************************************************** + * Included Files + ****************************************************************************/ + +#include + +#include +#include +#include +#include +#include + +#include "arm.h" + +/**************************************************************************** + * Pre-processor Definitions + ****************************************************************************/ + +#define BASE_ADDR_IRQ 0xfffffa00 +#define BASE_ADDR_IBOOT_EXC 0x0080001C + +enum irq_reg { + IT_REG1 = 0x00, + IT_REG2 = 0x02, + MASK_IT_REG1 = 0x08, + MASK_IT_REG2 = 0x0a, + IRQ_NUM = 0x10, + FIQ_NUM = 0x12, + IRQ_CTRL = 0x14, +}; + +#define ILR_IRQ(x) (0x20 + (x*2)) +#define IRQ_REG(x) ((void *)BASE_ADDR_IRQ + (x)) + +#ifndef ARRAY_SIZE +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) +#endif + +/**************************************************************************** + * Public Data + ****************************************************************************/ + +volatile uint32_t *current_regs; +extern uint32_t _exceptions; + +/**************************************************************************** + * Private Data + ****************************************************************************/ + +static uint8_t default_irq_prio[] = { + [IRQ_WATCHDOG] = 0xff, + [IRQ_TIMER1] = 0xff, + [IRQ_TIMER2] = 0xff, + [IRQ_TSP_RX] = 0, + [IRQ_TPU_FRAME] = 3, + [IRQ_TPU_PAGE] = 0xff, + [IRQ_SIMCARD] = 0xff, + [IRQ_UART_MODEM] = 8, + [IRQ_KEYPAD_GPIO] = 4, + [IRQ_RTC_TIMER] = 9, + [IRQ_RTC_ALARM_I2C] = 10, + [IRQ_ULPD_GAUGING] = 2, + [IRQ_EXTERNAL] = 12, + [IRQ_SPI] = 0xff, + [IRQ_DMA] = 0xff, + [IRQ_API] = 0xff, + [IRQ_SIM_DETECT] = 0, + [IRQ_EXTERNAL_FIQ] = 7, + [IRQ_UART_IRDA] = 2, + [IRQ_ULPD_GSM_TIMER] = 1, + [IRQ_GEA] = 0xff, +}; + +/**************************************************************************** + * Private Functions + ****************************************************************************/ + +static void _irq_enable(enum irq_nr nr, int enable) +{ + uint16_t *reg = IRQ_REG(MASK_IT_REG1); + uint16_t val; + + if (nr > 15) { + reg = IRQ_REG(MASK_IT_REG2); + nr -= 16; + } + + val = readw(reg); + if (enable) + val &= ~(1 << nr); + else + val |= (1 << nr); + writew(val, reg); +} + +static void set_default_priorities(void) +{ + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(default_irq_prio); i++) { + uint16_t val; + uint8_t prio = default_irq_prio[i]; + if (prio > 31) + prio = 31; + + val = readw(IRQ_REG(ILR_IRQ(i))); + val &= ~(0x1f << 2); + val |= prio << 2; + writew(val, IRQ_REG(ILR_IRQ(i))); + } +} + +/* Install the exception handlers to where the ROM loader jumps */ +static void calypso_exceptions_install(void) +{ + uint32_t *exceptions_dst = (uint32_t *) BASE_ADDR_IBOOT_EXC; + uint32_t *exceptions_src = &_exceptions; + int i; + + for (i = 0; i < 7; i++) + *exceptions_dst++ = *exceptions_src++; + +} + +/**************************************************************************** + * Public Functions + ****************************************************************************/ + +/**************************************************************************** + * Name: up_irqinitialize + * + * Description: + * Setup the IRQ and FIQ controllers + * + ****************************************************************************/ + +void up_irqinitialize(void) +{ + /* Prepare hardware */ + calypso_exceptions_install(); + current_regs = NULL; + + /* Switch to internal ROM */ + calypso_bootrom(1); + + /* set default priorities */ + set_default_priorities(); + + /* mask all interrupts off */ + writew(0xffff, IRQ_REG(MASK_IT_REG1)); + writew(0xffff, IRQ_REG(MASK_IT_REG2)); + + /* clear all pending interrupts */ + writew(0, IRQ_REG(IT_REG1)); + writew(0, IRQ_REG(IT_REG2)); + + /* enable interrupts globally to the ARM core */ +#ifndef CONFIG_SUPPRESS_INTERRUPTS + irqrestore(SVC_MODE | PSR_F_BIT); +#endif +} + +/**************************************************************************** + * Name: up_disable_irq + * + * Description: + * Disable the IRQ specified by 'irq' + * + ****************************************************************************/ + +void up_disable_irq(int irq) +{ + if((unsigned)irq < NR_IRQS) + _irq_enable(irq, 0); +} + +/**************************************************************************** + * Name: up_enable_irq + * + * Description: + * Enable the IRQ specified by 'irq' + * + ****************************************************************************/ + +void up_enable_irq(int irq) +{ + if((unsigned)irq < NR_IRQS) + _irq_enable(irq, 1); +} + +/**************************************************************************** + * Name: up_prioritize_irq + * + * Description: + * Set the priority of an IRQ. + * + ****************************************************************************/ + +#ifndef CONFIG_ARCH_IRQPRIO +int up_prioritize_irq(int nr, int prio) +{ + uint16_t val; + + if (prio == -1) + prio = default_irq_prio[nr]; + + if (prio > 31) + prio = 31; + + val = prio << 2; +/* + if (edge) + val |= 0x02; + if (fiq) + val |= 0x01; +*/ + writew(val, IRQ_REG(ILR_IRQ(nr))); + + return 0; // XXX: what's the return??? +} +#endif + +/**************************************************************************** + * Entry point for interrupts + ****************************************************************************/ + +void up_decodeirq(uint32_t *regs) +{ + uint8_t num, tmp; + uint32_t *saved_regs; + + /* XXX: What is this??? + * Passed to but ignored in IRQ handlers + * Only valid meaning is apparently non-NULL == IRQ context */ + saved_regs = (uint32_t *)current_regs; + current_regs = regs; + + /* Detect & deliver the IRQ */ + num = readb(IRQ_REG(IRQ_NUM)) & 0x1f; + irq_dispatch(num, regs); + + /* Start new IRQ agreement */ + tmp = readb(IRQ_REG(IRQ_CTRL)); + tmp |= 0x01; + writeb(tmp, IRQ_REG(IRQ_CTRL)); + + current_regs = saved_regs; +} + +/**************************************************************************** + * Entry point for FIQs + ****************************************************************************/ + +void calypso_fiq(void) +{ + uint8_t num, tmp; + uint32_t *regs; + + /* XXX: What is this??? + * Passed to but ignored in IRQ handlers + * Only valid meaning is apparently non-NULL == IRQ context */ + regs = (uint32_t *)current_regs; + current_regs = (uint32_t *)# + + /* Detect & deliver like an IRQ but we are in FIQ context */ + num = readb(IRQ_REG(FIQ_NUM)) & 0x1f; + irq_dispatch(num, regs); + + /* Start new FIQ agreement */ + tmp = readb(IRQ_REG(IRQ_CTRL)); + tmp |= 0x02; + writeb(tmp, IRQ_REG(IRQ_CTRL)); + + current_regs = regs; +} -- 1.7.1 From ichgeh at l--putt.de Tue May 24 21:06:41 2011 From: ichgeh at l--putt.de (l--putt) Date: Tue, 24 May 2011 23:06:41 +0200 Subject: [PATCH 4/4] Initial support for Nuttx on TI Calypso platform Message-ID: <4DDC1DE1.5000106@l--putt.de> From ichgeh at l--putt.de Tue May 24 19:19:17 2011 From: ichgeh at l--putt.de (Stefan Richter) Date: Tue, 24 May 2011 21:19:17 +0200 Subject: [PATCH 4/4] Initial support for Nuttx on TI Calypso platform: Memory initialization Switch lights in ostest example Message-ID: Now, nuttx.bin should build and run on your phone. No console output yet but turns on backlight of compal E99 and off when ostest has finished. --- apps/examples/ostest/main.c | 50 ++++++++++++++++++ nuttx/arch/arm/src/calypso/calypso_heap.c | 81 +++++++++++++++++++++++++++++ nuttx/arch/arm/src/common/up_internal.h | 3 +- 3 files changed, 133 insertions(+), 1 deletions(-) create mode 100644 nuttx/arch/arm/src/calypso/calypso_heap.c diff --git a/apps/examples/ostest/main.c b/apps/examples/ostest/main.c index 327ec60..641c3c9 100644 --- a/apps/examples/ostest/main.c +++ b/apps/examples/ostest/main.c @@ -33,6 +33,53 @@ * ****************************************************************************/ +/* + * Debug stuff for Compal E99 + * taken from Osmocom-BB init.c + * + * Turn on backlight on entry and off when done + */ + +#include +#include + +#define ARMIO_LATCH_OUT 0xfffe4802 +#define IO_CNTL_REG 0xfffe4804 +#define ASIC_CONF_REG 0xfffef008 + +static void lights_on(void) +{ + uint16_t reg; + + reg = readw(ASIC_CONF_REG); + /* LCD Set I/O(3) / SA0 to I/O(3) mode */ + reg &= ~( (1 << 12) | (1 << 10) | (1 << 7) | (1 << 1)) ; + /* don't set function pins to I2C Mode, C155 uses UWire */ + /* TWL3025: Set SPI+RIF RX clock to rising edge */ + reg |= (1 << 13) | (1 << 14); + writew(reg, ASIC_CONF_REG); + + /* LCD Set I/O(3) to output mode and enable C155 backlight (IO1) */ + /* FIXME: Put the display backlight control to backlight.c */ + reg = readw(IO_CNTL_REG); + reg &= ~( (1 << 3) | (1 << 1)); + writew(reg, IO_CNTL_REG); + + /* LCD Set I/O(3) output low */ + reg = readw(ARMIO_LATCH_OUT); + reg &= ~(1 << 3); + reg |= (1 << 1); + writew(reg, ARMIO_LATCH_OUT); +} + +static void lights_off(void) +{ + uint16_t reg; + reg = readw(ARMIO_LATCH_OUT); + reg &= ~(1 << 1); + writew(reg, ARMIO_LATCH_OUT); +} + /**************************************************************************** * Included Files ****************************************************************************/ @@ -421,6 +468,7 @@ static int user_main(int argc, char *argv[]) #endif } printf("user_main: Exitting\n"); + lights_off(); return 0; } @@ -457,6 +505,8 @@ int user_start(int argc, char *argv[]) { int result; + lights_on(); + /* Verify that stdio works first */ stdio_test(); diff --git a/nuttx/arch/arm/src/calypso/calypso_heap.c b/nuttx/arch/arm/src/calypso/calypso_heap.c new file mode 100644 index 0000000..d35a76f --- /dev/null +++ b/nuttx/arch/arm/src/calypso/calypso_heap.c @@ -0,0 +1,81 @@ +/**************************************************************************** + * calypso_heap.c + * Initialize memory interfaces of Calypso MCU + * + * Copyright (C) 2011 Stefan Richter + * + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * 3. Neither the name NuttX nor the names of its contributors may be + * used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + ****************************************************************************/ + +#include + +#include +#include + +#include +#include + +#include +#include + +#include "up_arch.h" +#include "up_internal.h" + +/**************************************************************************** + * Name: up_addregion + * + * Description: + * This function is called right after basics are initialized and right + * before IRQ system setup. + * + ****************************************************************************/ + +void up_addregion(void) +{ + /* Disable watchdog in first non-common function */ + wdog_enable(0); + + // XXX: change to initialization of extern memory with save defaults + /* Configure memory interface */ + calypso_mem_cfg(CALYPSO_nCS0, 3, CALYPSO_MEM_16bit, 1); + calypso_mem_cfg(CALYPSO_nCS1, 3, CALYPSO_MEM_16bit, 1); + calypso_mem_cfg(CALYPSO_nCS2, 5, CALYPSO_MEM_16bit, 1); + calypso_mem_cfg(CALYPSO_nCS3, 5, CALYPSO_MEM_16bit, 1); + calypso_mem_cfg(CALYPSO_CS4, 0, CALYPSO_MEM_8bit, 1); + calypso_mem_cfg(CALYPSO_nCS6, 0, CALYPSO_MEM_32bit, 1); + calypso_mem_cfg(CALYPSO_nCS7, 0, CALYPSO_MEM_32bit, 0); + + /* Set VTCXO_DIV2 = 1, configure PLL for 104 MHz and give ARM half of that */ + calypso_clock_set(2, CALYPSO_PLL13_104_MHZ, ARM_MCLK_DIV_2); + + /* Configure the RHEA bridge with some sane default values */ + calypso_rhea_cfg(0, 0, 0xff, 0, 1, 0, 0); +} diff --git a/nuttx/arch/arm/src/common/up_internal.h b/nuttx/arch/arm/src/common/up_internal.h index 803a656..21c34e2 100644 --- a/nuttx/arch/arm/src/common/up_internal.h +++ b/nuttx/arch/arm/src/common/up_internal.h @@ -64,9 +64,10 @@ #if CONFIG_NFILE_DESCRIPTORS == 0 || defined(CONFIG_DEV_LOWCONSOLE) # undef CONFIG_USE_SERIALDRIVER # undef CONFIG_USE_EARLYSERIALINIT + #elif defined(CONFIG_DEV_CONSOLE) && CONFIG_NFILE_DESCRIPTORS > 0 # define CONFIG_USE_SERIALDRIVER 1 -# define CONFIG_USE_EARLYSERIALINIT 1 +# undef CONFIG_USE_EARLYSERIALINIT #endif /* Check if an interrupt stack size is configured */ -- 1.7.1 From axel at walsleben.info Thu May 26 18:27:29 2011 From: axel at walsleben.info (Axel Walsleben) Date: Thu, 26 May 2011 20:27:29 +0200 Subject: Infineon PMB 6277 Chip Message-ID: <4DDE9B91.7030302@walsleben.info> hi list, does anybody knew a device that uses an Infineon PMB 6277 chip ? it is a quad band rf edge receiver chip. i got a full datasheet for it. ;) thanks axel -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 485 bytes Desc: not available URL: From anton.kochkov at gmail.com Thu May 26 19:01:31 2011 From: anton.kochkov at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQmtC+0YfQutC+0LI=?=) Date: Thu, 26 May 2011 23:01:31 +0400 Subject: Infineon PMB 6277 Chip In-Reply-To: <4DDE9B91.7030302@walsleben.info> References: <4DDE9B91.7030302@walsleben.info> Message-ID: Hello, Axel Walsleben! I'm know only device with Infineon SmartiUEm - PMB5703 This is Motorola Milestone/Milestone2 https://www.droid-developers.org/wiki/Motorola_Milestone Best regards, Anton Kochkov. On Thu, May 26, 2011 at 22:27, Axel Walsleben wrote: > hi list, > > does anybody knew a device that uses an Infineon PMB 6277 chip ? > it is a quad band rf edge receiver chip. > i got a full datasheet for it. ;) > > thanks > > axel > From jl at thre.at Thu May 26 20:06:30 2011 From: jl at thre.at (Joshua Lackey) Date: Thu, 26 May 2011 16:06:30 -0400 Subject: replacing the RX filter with a balun on the c139 Message-ID: <20110526200630.GA41133@thre.at> I've been going over Sylvain's report on removing the RX filters, http://www.246tnt.com/gsm/rx_filter.html, and I had some slight differences on the c139 that I'm hoping someone can help me with. Similar to Sylvain's experience, the schematic doesn't match reality. Just as Sylvain describes, the signal from the balanced output appears to be going through inductors rather than capacitors and there isn't a bridging inductor. However on my c139, the unbalanced input is missing the inductor to ground on the EGSM path and is missing the capacitor to ground on the DCS path. (Sylvain had a capacitor to ground on DCS where the schematic has an inductor to ground.) You can find a picture of what I'm looking at here: http://thre.at/c139/c139rxfilters.jpg . I've placed the c139 schematics in that directory as well, http://thre.at/c139 . My guess is that the filters in the schematics had a different unbalanced impedance than the ones they ended up placing on the c139. But I'm not an EE, and that is just a guess. I can't read the markings on the filters I have, so I can't check the unbalanced input from a data sheet. I also don't have a way to measure the components that are there now so I can't try and compute the value. My question is, does this matter? That is, should I use the same balun that Sylvain chose or should I find one with a different unbalanced impedance? Alternatively, should I use the same baluns and just install an inductor (or capacitor on DCS) to ground so that it matches Sylvain's c123? Any ideas? (As an aside, the baluns that Sylvain chose aren't perfect for the US frequency range, but they should work okay.) From 246tnt at gmail.com Thu May 26 20:41:22 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Thu, 26 May 2011 20:41:22 +0000 Subject: replacing the RX filter with a balun on the c139 In-Reply-To: <20110526200630.GA41133@thre.at> Message-ID: <0015175cd97e1b2f9c04a433d8cd@google.com> Hi, > My guess is that the filters in the schematics had a different > unbalanced impedance than the ones they ended up placing on the c139. > But I'm not an EE, and that is just a guess. Mmm, I doubt that. The filters probably had 50 ohm impedance as spec. But the circuit before that / the antenna maybe was a bit off and they tuned it, or it might just be cost optimized, or they just tested and it worked better like that. But anyway, it's probably tuned for 50 ohm unbalanced, so you can use it as is. > My question is, does this matter? Truth is ... not that much. If you look at the end of the page, you can see I tried the most botched up job _ever_ and it _still_ worked pretty good ! > That is, should I use the same balun > that Sylvain chose or should I find one with a different unbalanced > impedance? Alternatively, should I use the same baluns and just install > an inductor (or capacitor on DCS) to ground so that it matches Sylvain's Just use the same, it'll work fine. > (As an aside, the baluns that Sylvain chose aren't perfect for the US > frequency range, but they should work okay.) The hi band one if the one recommended for both PCS and DCS. For the low band it's indeed E-GSM but the graphs are virtually flat, insertion loss varies by less than 0.5 dB. Return losses are a bit higher but I doubt that it matters much. So yeah, not perfect but certainly not gonna be noticeable. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From jl at thre.at Fri May 27 02:58:13 2011 From: jl at thre.at (Joshua Lackey) Date: Thu, 26 May 2011 22:58:13 -0400 Subject: replacing the RX filter with a balun on the c139 In-Reply-To: <0015175cd97e1b2f9c04a433d8cd@google.com> References: <20110526200630.GA41133@thre.at> <0015175cd97e1b2f9c04a433d8cd@google.com> Message-ID: <20110527025813.GA52614@thre.at> Quoting 246tnt at gmail.com (246tnt at gmail.com): [...] > >(As an aside, the baluns that Sylvain chose aren't perfect for the US > >frequency range, but they should work okay.) > > The hi band one if the one recommended for both PCS and DCS. > For the low band it's indeed E-GSM but the graphs are virtually flat, > insertion loss varies by less than 0.5 dB. Return losses are a bit higher > but I doubt that it matters much. Yes, not "baluns" but "balun". The HHM1523C1 E-GSM side balun is slightly better in the 900 band. It looks like the HHM1523B3 is exactly the same balun with the same pin-out except slightly favoring the GSM-850 range. From 246tnt at gmail.com Thu May 26 20:47:50 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Thu, 26 May 2011 20:47:50 +0000 Subject: replacing the RX filter with a balun on the c139 In-Reply-To: <20110526200630.GA41133@thre.at> Message-ID: <90e6ba61507039089004a433ef58@google.com> > You can find a picture of what I'm looking at here: > http://thre.at/c139/c139rxfilters.jpg . I've placed the c139 schematics > in that directory as well, http://thre.at/c139 . As a side note, you should use the quadband branch (soon to be merged) and replace (in board/compal/rffe_dualband.c) uint32_t rffe_get_rx_ports(void) { return (1 << PORT_LO) | (1 << PORT_DCS1800); } by uint32_t rffe_get_rx_ports(void) { return (1 << PORT_LO) | (1 << PORT_PCS1900); } because the hi band input is plugged to the PCS port of rita and not DCS port. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From jl at thre.at Fri May 27 02:26:33 2011 From: jl at thre.at (Joshua Lackey) Date: Thu, 26 May 2011 22:26:33 -0400 Subject: replacing the RX filter with a balun on the c139 In-Reply-To: <90e6ba61507039089004a433ef58@google.com> References: <20110526200630.GA41133@thre.at> <90e6ba61507039089004a433ef58@google.com> Message-ID: <20110527022633.GA50678@thre.at> Quoting 246tnt at gmail.com (246tnt at gmail.com): > >You can find a picture of what I'm looking at here: > >http://thre.at/c139/c139rxfilters.jpg . I've placed the c139 schematics > >in that directory as well, http://thre.at/c139 . > > As a side note, you should use the quadband branch (soon to be merged) and > replace (in board/compal/rffe_dualband.c) I've been using a merge of your quadband and your burst_ind branches. > > uint32_t rffe_get_rx_ports(void) > { > return (1 << PORT_LO) | (1 << PORT_DCS1800); > } > > by > > uint32_t rffe_get_rx_ports(void) > { > return (1 << PORT_LO) | (1 << PORT_PCS1900); > } > > because the hi band input is plugged to the PCS port of rita and not DCS > port. Ah, thanks for the tip. My local tower only has GSM850 channels so I haven't noticed a problem. I'll make that change though on my local branch. From weberbe at ee.ethz.ch Fri May 27 07:57:31 2011 From: weberbe at ee.ethz.ch (weberbe at ee.ethz.ch) Date: Fri, 27 May 2011 09:57:31 +0200 Subject: mobile crashes Message-ID: <20110527095731.592221m5cw98lkyz@email.ee.ethz.ch> Hi guys I just run into a problem and was wondering whether anybody has experienced the same: When I start mobile with GSMTAB support (./mobile -i localhost) it crashes immediately after the first GSMTAB packet was sent. Any ideas or remedies? I compiled the current master branch and am using Ubuntu 11.04 Ben From 246tnt at gmail.com Fri May 27 08:10:49 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 27 May 2011 10:10:49 +0200 Subject: mobile crashes In-Reply-To: <20110527095731.592221m5cw98lkyz@email.ee.ethz.ch> References: <20110527095731.592221m5cw98lkyz@email.ee.ethz.ch> Message-ID: Hi, > I just run into a problem and was wondering whether anybody has experienced > the same: > > When I start mobile with GSMTAB support (./mobile -i localhost) it crashes > immediately after the first GSMTAB packet was sent. Any ideas or remedies? > > I compiled the current master branch and am using Ubuntu 11.04 Yes, I have the same and didn't get a chance to debug it yet ... If you find the problem before I do, patches are welcome :p Cheers, Sylvain From laforge at gnumonks.org Fri May 27 14:44:50 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 27 May 2011 16:44:50 +0200 Subject: mobile crashes In-Reply-To: <20110527095731.592221m5cw98lkyz@email.ee.ethz.ch> References: <20110527095731.592221m5cw98lkyz@email.ee.ethz.ch> Message-ID: <20110527144450.GA7551@prithivi.gnumonks.org> On Fri, May 27, 2011 at 09:57:31AM +0200, weberbe at ee.ethz.ch wrote: > Hi guys > > I just run into a problem and was wondering whether anybody has > experienced the same: > > When I start mobile with GSMTAB support (./mobile -i localhost) it > crashes immediately after the first GSMTAB packet was sent. Any > ideas or remedies? This should be fixed now, specifically with the following commit in libosmocore: 4d3a7b124e08a597d5f01fb2a71f3a4677a360a9 -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Fri May 27 15:52:57 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Fri, 27 May 2011 15:52:57 +0000 Subject: mobile crashes In-Reply-To: <20110527144450.GA7551@prithivi.gnumonks.org> Message-ID: > This should be fixed now, specifically with the following commit in > libosmocore: 4d3a7b124e08a597d5f01fb2a71f3a4677a360a9 Ah, but it's not yet in osmocom-bb tree so maybe that's the issue. I don't know which libosmocore gets used at runtime. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri May 27 16:17:48 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 27 May 2011 18:17:48 +0200 Subject: mobile crashes In-Reply-To: References: <20110527144450.GA7551@prithivi.gnumonks.org> Message-ID: <20110527161748.GD7551@prithivi.gnumonks.org> On Fri, May 27, 2011 at 03:52:57PM +0000, 246tnt at gmail.com wrote: > >This should be fixed now, specifically with the following commit in > >libosmocore: 4d3a7b124e08a597d5f01fb2a71f3a4677a360a9 > > Ah, but it's not yet in osmocom-bb tree Ok, thanks for noticing. I'm updating it with git-subtree right now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sun May 29 17:50:50 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 29 May 2011 19:50:50 +0200 Subject: mobile crashes In-Reply-To: <20110527161748.GD7551@prithivi.gnumonks.org> References: <20110527144450.GA7551@prithivi.gnumonks.org> <20110527161748.GD7551@prithivi.gnumonks.org> Message-ID: Ok, it took a few spins but I think that's now fixed. There was several bugs it seems. Sylvain From weberbe at ee.ethz.ch Sun May 29 20:06:41 2011 From: weberbe at ee.ethz.ch (weberbe at ee.ethz.ch) Date: Sun, 29 May 2011 22:06:41 +0200 Subject: mobile crashes In-Reply-To: References: <20110527144450.GA7551@prithivi.gnumonks.org> <20110527161748.GD7551@prithivi.gnumonks.org> Message-ID: <20110529220641.161734ki3j7ju8up@email.ee.ethz.ch> Thanks a lot works smoothly now Quoting "Sylvain Munaut" <246tnt at gmail.com>: > Ok, it took a few spins but I think that's now fixed. > > There was several bugs it seems. > > > Sylvain > From drasko.draskovic at gmail.com Sun May 29 22:34:08 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 30 May 2011 00:34:08 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) Message-ID: Hi all, going through the documentation, I am trying to figure out what would be the best way to have whole protocol stack communication with OsmocomBB. Now, I understand that osmocon can be used to load layer1 into phones RAM, so that this code turns on Calypso and communicate with DSP with AT commands. Then osmocon gets messages from layer1 via RS232 and can distribute them to the mobile application, which sends them to layer23 for further processing or via GSM tap to Wireshark or outputs them on stdout. What I am most interested in how do we insert pacgaes on the other side of the stack, i.e. via telephone air interface (packets that will traverse through Rita, Iota, Calypso down to stdout of host). From what I understand we need some kind of BTS, and I can see that GNU Radio is used for this purpose. But for this, as I understand USPRP (http://en.wikipedia.org/wiki/Universal_Software_Radio_Peripheral) FPGA motherboard with both RX and TX doughterboards is needed, which can go up to 1k eur (too expensive for a hobbist). I was wondering so, what is the best and the cheapest way to inject packets at the protocol stack on the phone and analyze some packet flow later with Wireshark - i.e. to get some usage of the OsmocomBB and to see how it works. At this point I can only run Hello World application, or "mobile" app without any usage (or I do not know how to use it). What would be the best way to start playing around without spending too much money. Speaking of this, what would be the price of the cheapest existing packet generator that can transmit them via Um (i.e. what is the price of the cheapest BTS)? Is there some open source FPGA that can be used for this purpose? Thanks for your explanations and best regards, Drasko From 246tnt at gmail.com Sun May 29 23:22:44 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 30 May 2011 01:22:44 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: References: Message-ID: Hi, > Now, I understand that osmocon can be used to load layer1 into phones > RAM, so that this code turns on Calypso and communicate with DSP with > AT commands. ... there is no AT commands anywhere ... > What I am most interested in how do we insert pacgaes on the other > side of the stack, i.e. via telephone air interface (packets that will > traverse through Rita, Iota, Calypso down to stdout of host). From > what I understand we need some kind of BTS, and I can see that GNU > Radio is used for this purpose. But for this, as I understand USPRP If you want to inject packet towards a phone, yes you need your own BTS. OpenBTS using a USRP is one possibility. > (http://en.wikipedia.org/wiki/Universal_Software_Radio_Peripheral) > FPGA motherboard with both RX and TX doughterboards is needed, which > can go up to 1k eur (too expensive for a hobbist). Depends how motivated the hobbyist is ... I know _plenty_ of people that pay _way_ more for their hobby. HAM radio amateurs have a lot of pricy gear for instance. And it's not just EE. I know guys that like riding motorcycle, how much do you think that cost ? Or recreational shooting ... guns cost a lot and each clip fired is literally 5$ up in smoke. People keep saying the USRP is very expensive ... well, not so much really. > Speaking of this, what would be the price of the cheapest existing > packet generator that can transmit them via Um (i.e. what is the price > of the cheapest BTS)? The USRP is the cheapest widely available option. Two notes: - You can sometime find BTS on ebay (ip.access nanoBTS, google for it), but those have been very rare lately AFAICT. (by rare, I mean none at all that I could see) - Several other options are actively being developped, but none will be available in the short term AFAIK. > Is there some open source FPGA that can be used for this purpose? The USRP and board schematics can be found ... and the sw is all opensource. You're free to build one yourself. Of course it's gonna cost you way more than buying one. There is no cheaper, currently available, SDR platform that can run OpenBTS AFAIK. Cheers, Sylvain From drasko.draskovic at gmail.com Sun May 29 23:58:37 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 30 May 2011 01:58:37 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: References: Message-ID: On Mon, May 30, 2011 at 1:22 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > >> Now, I understand that osmocon can be used to load layer1 into phones >> RAM, so that this code turns on Calypso and communicate with DSP with >> AT commands. > > ... there is no AT commands anywhere ... Oh... I thought that firmware on ARM was communicating with DSP via AT messages... How does it control DSP then? I see that data is exchanged via shared memory in SRAM, but how does Calypso call DSP interface to do some processing ? >> (http://en.wikipedia.org/wiki/Universal_Software_Radio_Peripheral) >> FPGA motherboard with both RX and TX doughterboards is needed, which >> can go up to 1k eur (too expensive for a hobbist). > > Depends how motivated the hobbyist is ... I know _plenty_ of people > that pay _way_ more for their hobby. I agree with you, but imagine someone who is looking around from the distance at one very interesting project. Fistly, I am not network stack engineer, but more attracted by the platform and system. But I'd like to get my feet wet, and not ready to throw 1k eur on the equipment I do not know at all. I'd rather try things around, get a feel and then, as I get involved, collect some material. You might disagree with me, but I think that for open source projects related to HW price is very important - keeping the price very low helps more people get involved in the project in the first place. Here, I ended up with telephone that can not do practicaly anything - can not receive nor transmit packets. Or am I wrong ? Can I use some data from public network, just to see some packets flow, so I can at least get some feel ? > Or recreational shooting ... guns cost a lot and each clip > fired is literally 5$ up in smoke. This does not surprise me much, world is full of morons. On the other side of the planet someone is litteraly dying for this $5. > People keep saying the USRP is very expensive ... well, not so much really. I can agree on this, it is not so expensive. But I explained position, so at this moment I am reconsidering solutions. >> Is there some open source FPGA that can be used for this purpose? > > The USRP and board schematics can be found ... and the sw is all opensource. When you say SW, I guess you mean some host applications ? What I was talking about is available HDL code that I can flash into my (eventually modified) FPGA board. > You're free to build one yourself. Of course it's gonna cost you way > more than buying one. I would more opt for idea of open source VHDL or Verilog code that can be flashed into non-expensive FPGA development boards (some Spartan or Altera or something) and open source schematics for additional hardware that can be soldered around to have signals coming. At this point I am not interested at full-blown BTS, but some minimal stuff that can send something via radio link that would be captured by the phone and transmitted via stack towards Wireshark on the host. Just the basic test. I do not need it for GSM protocol reserach, rather something that can give feel and usability to the OsmocomBB project, before someone has enough informations and idea to buy USRP. BR, Drasko From 246tnt at gmail.com Mon May 30 00:02:04 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Mon, 30 May 2011 00:02:04 +0000 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: Message-ID: <0016364c7564647c6304a472ffdf@google.com> > This does not surprise me much, world is full of morons. Guess what, I'm one of them ... I think I'll let someone else answer your questions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drasko.draskovic at gmail.com Mon May 30 12:03:54 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 30 May 2011 14:03:54 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: <0016364c7564647c6304a472ffdf@google.com> References: <0016364c7564647c6304a472ffdf@google.com> Message-ID: On Mon, May 30, 2011 at 2:02 AM, <246tnt at gmail.com> wrote: >> This does not surprise me much, world is full of morons. > > Guess what, I'm one of them ... I think I'll let someone else answer your > questions. There is no need to take this personally, it was not my intention to sound too rude. It was more ironic social-awareness critic then an insult. Sorry if that offended you. In any case, I'd like to keep this interesting discussion strictly technical from now on, as I am sure that many people might benefit from it. Taken in a count that majority of engineers who are willing to contribute their time and knowledge to this project have probably mid-level expertise, with few real experts orbiting around and sharing the knowledge and support, paving the way for the newcomers. That's why I think that discussion I started makes sense and can be beneficial to all who have some general embedded engineering experience (in which I count myself) and are looking for a best way to contribute it to OsmocomBB and the community. I hope that you will share your valuable experience in this effort. I am aware of your work and I know that it is highly appreciated in the community. Thank you for your help and support. Best regards, Drasko From weberbe at ee.ethz.ch Mon May 30 06:56:54 2011 From: weberbe at ee.ethz.ch (weberbe at ee.ethz.ch) Date: Mon, 30 May 2011 08:56:54 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: References: Message-ID: <20110530085654.767746elephttr5i@email.ee.ethz.ch> Quoting "Drasko DRASKOVIC" : > On Mon, May 30, 2011 at 1:22 AM, Sylvain Munaut <246tnt at gmail.com> wrote: >> Hi, >> >> >>> Now, I understand that osmocon can be used to load layer1 into phones >>> RAM, so that this code turns on Calypso and communicate with DSP with >>> AT commands. >> >> ... there is no AT commands anywhere ... > Oh... I thought that firmware on ARM was communicating with DSP via AT > messages... How does it control DSP then? I see that data is exchanged > via shared memory in SRAM, but how does Calypso call DSP interface to > do some processing ? > > >>> (http://en.wikipedia.org/wiki/Universal_Software_Radio_Peripheral) >>> FPGA motherboard with both RX and TX doughterboards is needed, which >>> can go up to 1k eur (too expensive for a hobbist). >> >> Depends how motivated the hobbyist is ... I know _plenty_ of people >> that pay _way_ more for their hobby. > > I agree with you, but imagine someone who is looking around from the > distance at one very interesting project. Fistly, I am not network > stack engineer, but more attracted by the platform and system. But I'd > like to get my feet wet, and not ready to throw 1k eur on the > equipment I do not know at all. I'd rather try things around, get a > feel and then, as I get involved, collect some material. You might > disagree with me, but I think that for open source projects related to > HW price is very important - keeping the price very low helps more > people get involved in the project in the first place. > > Here, I ended up with telephone that can not do practicaly anything - > can not receive nor transmit packets. Or am I wrong ? Can I use some > data from public network, just to see some packets flow, so I can at > least get some feel ? > > >> Or recreational shooting ... guns cost a lot and each clip >> fired is literally 5$ up in smoke. > This does not surprise me much, world is full of morons. On the other > side of the planet someone is litteraly dying for this $5. > > >> People keep saying the USRP is very expensive ... well, not so much really. > I can agree on this, it is not so expensive. But I explained position, > so at this moment I am reconsidering solutions. > >>> Is there some open source FPGA that can be used for this purpose? >> >> The USRP and board schematics can be found ... and the sw is all opensource. > When you say SW, I guess you mean some host applications ? > > What I was talking about is available HDL code that I can flash into > my (eventually modified) FPGA board. > >> You're free to build one yourself. Of course it's gonna cost you way >> more than buying one. > > I would more opt for idea of open source VHDL or Verilog code that can > be flashed into non-expensive FPGA development boards (some Spartan or > Altera or something) and open source schematics for additional > hardware that can be soldered around to have signals coming. > > At this point I am not interested at full-blown BTS, but some minimal > stuff that can send something via radio link that would be captured by > the phone and transmitted via stack towards Wireshark on the host. As this is all you want just use the signal from any commercial BTS in your area. OsmocomBB is able to capture System Information Messages and Paging Requests and forward the content to Wireshark. > Just the basic test. I do not need it for GSM protocol reserach, > rather something that can give feel and usability to the OsmocomBB > project, before someone has enough informations and idea to buy USRP. > > BR, > Drasko > From drasko.draskovic at gmail.com Mon May 30 08:11:25 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 30 May 2011 10:11:25 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: <20110530085654.767746elephttr5i@email.ee.ethz.ch> References: <20110530085654.767746elephttr5i@email.ee.ethz.ch> Message-ID: On Mon, May 30, 2011 at 8:56 AM, wrote: > Quoting "Drasko DRASKOVIC" : > As this is all you want just use the signal from any commercial BTS in your > area. OsmocomBB is able to capture System Information Messages and Paging > Requests and forward the content to Wireshark. Yes, I think it would be a great start ! How this can be done ? Can somebody kindly explain the procedure to do this in a few words, and point out things to observe ? I think this kind of instructions/tutorial can be very useful for all the people who want to start quickly with OsmocomBB and have something useful that does communication and traverse packets through the stack. This employs all the tools from the project and gives perfect overview how they work together. Thanks and best regards, Drasko From gianni at scaramanga.co.uk Mon May 30 16:46:38 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 30 May 2011 17:46:38 +0100 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: References: <20110530085654.767746elephttr5i@email.ee.ethz.ch> Message-ID: <1306773998.9713.0.camel@deckard> On Mon, 2011-05-30 at 10:11 +0200, Drasko DRASKOVIC wrote: > On Mon, May 30, 2011 at 8:56 AM, wrote: > > Quoting "Drasko DRASKOVIC" : > > > As this is all you want just use the signal from any commercial BTS in your > > area. OsmocomBB is able to capture System Information Messages and Paging > > Requests and forward the content to Wireshark. > > Yes, I think it would be a great start ! How this can be done ? > > Can somebody kindly explain the procedure to do this in a few words, > and point out things to observe ? I think this kind of > instructions/tutorial can be very useful for all the people who want > to start quickly with OsmocomBB and have something useful that does > communication and traverse packets through the stack. This employs all > the tools from the project and gives perfect overview how they work > together. You can find exactly this tutorial on the wiki. Gianni From drasko.draskovic at gmail.com Mon May 30 17:13:25 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 30 May 2011 19:13:25 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: <1306773998.9713.0.camel@deckard> References: <20110530085654.767746elephttr5i@email.ee.ethz.ch> <1306773998.9713.0.camel@deckard> Message-ID: On Mon, May 30, 2011 at 6:46 PM, Gianni Tedesco wrote: > > You can find exactly this tutorial on the wiki. Hi Gianni, I did not saw it last night when I was srtawling through the wiki (or more possible did not understand that I was looking at it). Can you please post the link for the future reference ? BR, Drasko From drasko.draskovic at gmail.com Mon May 30 22:05:40 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Tue, 31 May 2011 00:05:40 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: References: <20110530085654.767746elephttr5i@email.ee.ethz.ch> <1306773998.9713.0.camel@deckard> Message-ID: Hi Gianni, after few hours of searching through the wiki pages, I have not been able to find the document you were mentioning that would explain attaching to cell and have some packet transfered through protocol stack up to the Wireshark. Are you sure that this document still exist and not have been removed/replaced ? All I have found that can resemble is this : http://bb.osmocom.org/trac/wiki/layer23 but I guess that this is not what you are talking about, as it gives no detailed instructions for the things I want to obtain (i.e. which applications to start, in which order, what are things to observe, etc...). I tried some basic test by watching OsocomBB video presentations, as these are closest instructions and recepies on tools usage I have found to get one up and running, and I described troubles I have been facing in previous mail - I tried to guess what can be the right scenario as I find no docs, but I am still not able to synchronize to any cell, nor have some packets coming... BR, Drasko On Mon, May 30, 2011 at 7:13 PM, Drasko DRASKOVIC wrote: > On Mon, May 30, 2011 at 6:46 PM, Gianni Tedesco wrote: >> >> You can find exactly this tutorial on the wiki. > > Hi Gianni, > I did not saw it last night when I was srtawling through the wiki (or > more possible did not understand that I was looking at it). > > Can you please post the link for the future reference ? > > BR, > Drasko > From gianni at scaramanga.co.uk Mon May 30 22:18:24 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 30 May 2011 23:18:24 +0100 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: References: <20110530085654.767746elephttr5i@email.ee.ethz.ch> <1306773998.9713.0.camel@deckard> Message-ID: <1306793904.15043.13.camel@deckard> On Tue, 2011-05-31 at 00:05 +0200, Drasko DRASKOVIC wrote: > Hi Gianni, > after few hours of searching through the wiki pages, I have not been > able to find the document you were mentioning that would explain > attaching to cell and have some packet transfered through protocol > stack up to the Wireshark. > > Are you sure that this document still exist and not have been removed/replaced ? > > All I have found that can resemble is this : > http://bb.osmocom.org/trac/wiki/layer23 > but I guess that this is not what you are talking about, as it gives > no detailed instructions for the things I want to obtain (i.e. which > applications to start, in which order, what are things to observe, > etc...). Pretty much, but also look at the page for your specific phone model and http://bb.osmocom.org/trac/wiki/osmocon Basically you just need to use osmocon to load the layer1 firmware, power the phone up and then if 'mobile' (or whatever app you want) is running, it should be "all systems go". You can run mobile/cell_log/whatever before or after booting the phone and it'll be fine. > I tried some basic test by watching OsocomBB video presentations, as > these are closest instructions and recepies on tools usage I have > found to get one up and running, and I described troubles I have been > facing in previous mail - I tried to guess what can be the right > scenario as I find no docs, but I am still not able to synchronize to > any cell, nor have some packets coming... It's not a complicated scenario and is well explained on the wiki: We have a firmware for the phone that we compiled on the PC We have a data cable between phone and PC The firmware does low level things Other apps running on the PC do high level things (eg. mobile phone) We use a loader program (osmocon) to load the firmware from the PC on to the phone via the cable. After the firmware is running on the phone, we can run high level apps on the PC (mobile, cell_log, etc). The high level apps communicate to the phone via the communication channel setup by the loader. Most (all?) of the high level apps have a command line switch which tells them to transmit GSMTAP logs to a specific IP address. You can use tcpdump to capture the GSMTAP info and view it in wireshark. Gianni From drasko.draskovic at gmail.com Mon May 30 22:31:21 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Tue, 31 May 2011 00:31:21 +0200 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: <1306793904.15043.13.camel@deckard> References: <20110530085654.767746elephttr5i@email.ee.ethz.ch> <1306773998.9713.0.camel@deckard> <1306793904.15043.13.camel@deckard> Message-ID: On Tue, May 31, 2011 at 12:18 AM, Gianni Tedesco wrote: > On Tue, 2011-05-31 at 00:05 +0200, Drasko DRASKOVIC wrote: >> Hi Gianni, >> after few hours of searching through the wiki pages, I have not been >> able to find the document you were mentioning that would explain >> attaching to cell and have some packet transfered through protocol >> stack up to the Wireshark. >> >> Are you sure that this document still exist and not have been removed/replaced ? >> >> All I have found that can resemble is this : >> http://bb.osmocom.org/trac/wiki/layer23 >> but I guess that this is not what you are talking about, as it gives >> no detailed instructions for the things I want to obtain (i.e. which >> applications to start, in which order, what are things to observe, >> etc...). > > Pretty much, but also look at the page for your specific phone model and > http://bb.osmocom.org/trac/wiki/osmocon > > Basically you just need to use osmocon to load the layer1 firmware, > power the phone up and then if 'mobile' (or whatever app you want) is > running, it should be "all systems go". You can run > mobile/cell_log/whatever before or after booting the phone and it'll be > fine. > >> I tried some basic test by watching OsocomBB video presentations, as >> these are closest instructions and recepies on tools usage I have >> found to get one up and running, and I described troubles I have been >> facing in previous mail - I tried to guess what can be the right >> scenario as I find no docs, but I am still not able to synchronize to >> any cell, nor have some packets coming... > > It's not a complicated scenario and is well explained on the wiki: > > We have a firmware for the phone that we compiled on the PC > > We have a data cable between phone and PC > > The firmware does low level things > > Other apps running on the PC do high level things (eg. mobile phone) > > We use a loader program (osmocon) to load the firmware from the PC on to > the phone via the cable. > > After the firmware is running on the phone, we can run high level apps > on the PC (mobile, cell_log, etc). > > The high level apps communicate to the phone via the communication > channel setup by the loader. > > Most (all?) of the high level apps have a command line switch which > tells them to transmit GSMTAP logs to a specific IP address. > > You can use tcpdump to capture the GSMTAP info and view it in wireshark. Yes, thanks. I gotten that. What I meant is more like some instructions how to get the system running, this what I am trying to achieve. Now, as you can see there is a lot of information spread all around and I have hard time to get them together in a meaningful picture. What troubles me the most is these kind of information that are missing, for example : - start this application first, then this one - LOST message is OK - there is no SIM simulated, and you can not do anything without SIM, which is not supported on the master - connect this to this to get logs in Wireshark - etc... Some kind of a tutorial that would prevent every starter to get stuck. Thanks for your help, things are beginning to be clearer. BR, Drasko From gianni at scaramanga.co.uk Mon May 30 22:42:48 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 30 May 2011 23:42:48 +0100 Subject: Testing protocol stack with OsmocomBB (cheap way) In-Reply-To: References: <20110530085654.767746elephttr5i@email.ee.ethz.ch> <1306773998.9713.0.camel@deckard> <1306793904.15043.13.camel@deckard> Message-ID: <1306795368.15043.23.camel@deckard> On Tue, 2011-05-31 at 00:31 +0200, Drasko DRASKOVIC wrote: > On Tue, May 31, 2011 at 12:18 AM, Gianni Tedesco > wrote: > > On Tue, 2011-05-31 at 00:05 +0200, Drasko DRASKOVIC wrote: > >> Hi Gianni, > >> after few hours of searching through the wiki pages, I have not been > >> able to find the document you were mentioning that would explain > >> attaching to cell and have some packet transfered through protocol > >> stack up to the Wireshark. > >> > >> Are you sure that this document still exist and not have been removed/replaced ? > >> > >> All I have found that can resemble is this : > >> http://bb.osmocom.org/trac/wiki/layer23 > >> but I guess that this is not what you are talking about, as it gives > >> no detailed instructions for the things I want to obtain (i.e. which > >> applications to start, in which order, what are things to observe, > >> etc...). > > > > Pretty much, but also look at the page for your specific phone model and > > http://bb.osmocom.org/trac/wiki/osmocon > > > > Basically you just need to use osmocon to load the layer1 firmware, > > power the phone up and then if 'mobile' (or whatever app you want) is > > running, it should be "all systems go". You can run > > mobile/cell_log/whatever before or after booting the phone and it'll be > > fine. > > > >> I tried some basic test by watching OsocomBB video presentations, as > >> these are closest instructions and recepies on tools usage I have > >> found to get one up and running, and I described troubles I have been > >> facing in previous mail - I tried to guess what can be the right > >> scenario as I find no docs, but I am still not able to synchronize to > >> any cell, nor have some packets coming... > > > > It's not a complicated scenario and is well explained on the wiki: > > > > We have a firmware for the phone that we compiled on the PC > > > > We have a data cable between phone and PC > > > > The firmware does low level things > > > > Other apps running on the PC do high level things (eg. mobile phone) > > > > We use a loader program (osmocon) to load the firmware from the PC on to > > the phone via the cable. > > > > After the firmware is running on the phone, we can run high level apps > > on the PC (mobile, cell_log, etc). > > > > The high level apps communicate to the phone via the communication > > channel setup by the loader. > > > > Most (all?) of the high level apps have a command line switch which > > tells them to transmit GSMTAP logs to a specific IP address. > > > > You can use tcpdump to capture the GSMTAP info and view it in wireshark. > > Yes, thanks. I gotten that. What I meant is more like some > instructions how to get the system running, this what I am trying to > achieve. Now, as you can see there is a lot of information spread all > around and I have hard time to get them together in a meaningful > picture. > > What troubles me the most is these kind of information that are > missing, for example : > - start this application first, then this one > - LOST message is OK > - there is no SIM simulated, and you can not do anything without SIM, > which is not supported on the master > - connect this to this to get logs in Wireshark > - etc... > > Some kind of a tutorial that would prevent every starter to get stuck. Sure. Although it is a goal of the project to bring awareness, knowledge, access to GSM to a wider audience, osmocom is still highly experimental software and that means that to do anything useful with it you are going to need to be very comfortable with figuring out these sorts of issues anyway. I mean, at this stage it's still very much for hackers who are ready to roll their sleeves up and get stuck in. I must say, I didn't even know of sylvains driver (non obvious branch name) or cell_log and had to write my own SIM access code to get going - it was a fun night :) Gianni From weberbe at ee.ethz.ch Mon May 30 07:08:11 2011 From: weberbe at ee.ethz.ch (weberbe at ee.ethz.ch) Date: Mon, 30 May 2011 09:08:11 +0200 Subject: Invitation Message-ID: <20110530090811.92964aoxdlov50t7@email.ee.ethz.ch> Hi list First of all: Thanks to all of you who actively develop OsmocomBB. Second: In the past few months I worked on an interface between a GSM transceiver and ABB towards the mobile application from OsmocomBB. The findings will be presented Tuesday, May 31, 1.55 pm in ETZ J64 at ETH in Zurich (Gloriastrasse 35, 8092 Z?rich). You are all invited. The goal of this project was to understand the GSM protocol flow better in order to be able to extend the hardware towards higher layers. To this end, the mobile application (L2 and L3) was used. Benjamin From lists at infosecurity.ch Mon May 30 08:09:41 2011 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Mon, 30 May 2011 10:09:41 +0200 Subject: Invitation In-Reply-To: <20110530090811.92964aoxdlov50t7@email.ee.ethz.ch> References: <20110530090811.92964aoxdlov50t7@email.ee.ethz.ch> Message-ID: <4DE350C5.6090301@infosecurity.ch> On 5/30/11 9:08 AM, weberbe at ee.ethz.ch wrote: > Hi list > > First of all: Thanks to all of you who actively develop OsmocomBB. > Second: In the past few months I worked on an interface between a GSM > transceiver and ABB towards the mobile application from OsmocomBB. The > findings will be presented Tuesday, May 31, 1.55 pm in ETZ J64 at ETH in > Zurich (Gloriastrasse 35, 8092 Z?rich). You are all invited. > The goal of this project was to understand the GSM protocol flow better > in order to be able to extend the hardware towards higher layers. To > this end, the mobile application (L2 and L3) was used. For who will not be able to be there to look the presentation in Zurich, there will be a website with published papers / source codes about it? -naif From uli.radiotux at googlemail.com Mon May 30 14:56:29 2011 From: uli.radiotux at googlemail.com (Uli Kleemann) Date: Mon, 30 May 2011 16:56:29 +0200 Subject: target/firmware/board/compal_e88/loader.compalram.bin T191 cable out of order Message-ID: Hi Konrad, sorry for that but anyway thanks for your advice with the software. Which software would you like to recommend to fix that? Regards, -- Uli Kleemann -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfram at the-dreams.de Mon May 30 18:03:16 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 30 May 2011 20:03:16 +0200 Subject: [PATCH 1/2] mtk: uart: remove forgotten calypso-include Message-ID: <1306778597-27870-1-git-send-email-wolfram@the-dreams.de> Dunno how that survived... Signed-off-by: Wolfram Sang --- src/target/firmware/board/mediatek/uart.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/target/firmware/board/mediatek/uart.c b/src/target/firmware/board/mediatek/uart.c index ff82245..8e86b20 100644 --- a/src/target/firmware/board/mediatek/uart.c +++ b/src/target/firmware/board/mediatek/uart.c @@ -36,8 +36,6 @@ #include -#include - /* MT622x */ #if 0 #define BASE_ADDR_UART1 0x80130000 -- 1.7.2.5 From wolfram at the-dreams.de Mon May 30 18:03:17 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 30 May 2011 20:03:17 +0200 Subject: [PATCH 2/2] board: mtk: increase RAM sizes in linker script In-Reply-To: <1306778597-27870-1-git-send-email-wolfram@the-dreams.de> References: <1306778597-27870-1-git-send-email-wolfram@the-dreams.de> Message-ID: <1306778597-27870-2-git-send-email-wolfram@the-dreams.de> gcc3 (and some gcc4) produce code which does not fit into the 0x5000-sized RAM sections. Extend them to 0x6000 for now, so it will build correctly again. The created binary (gcc3) has been successfully tested on my G2. Signed-off-by: Wolfram Sang --- src/target/firmware/board/mediatek/ram.lds | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/target/firmware/board/mediatek/ram.lds b/src/target/firmware/board/mediatek/ram.lds index 465c0ba..a2af560 100644 --- a/src/target/firmware/board/mediatek/ram.lds +++ b/src/target/firmware/board/mediatek/ram.lds @@ -11,9 +11,9 @@ ENTRY(_start) MEMORY { /* mtk-loaded binary: our text, initialized data */ - LRAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00005000 + LRAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00006000 /* mtk-loaded binary: our unitialized data, stacks, heap */ - IRAM (rw) : ORIGIN = 0x40005000, LENGTH = 0x00005000 + IRAM (rw) : ORIGIN = 0x40006000, LENGTH = 0x00006000 } SECTIONS { -- 1.7.2.5 From laforge at gnumonks.org Mon May 30 19:52:22 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 30 May 2011 21:52:22 +0200 Subject: [PATCH 2/2] board: mtk: increase RAM sizes in linker script In-Reply-To: <1306778597-27870-2-git-send-email-wolfram@the-dreams.de> References: <1306778597-27870-1-git-send-email-wolfram@the-dreams.de> <1306778597-27870-2-git-send-email-wolfram@the-dreams.de> Message-ID: <20110530195222.GF14428@prithivi.gnumonks.org> Hi Wolfgang, On Mon, May 30, 2011 at 08:03:17PM +0200, Wolfram Sang wrote: > gcc3 (and some gcc4) produce code which does not fit into the > 0x5000-sized RAM sections. Extend them to 0x6000 for now, so it will > build correctly again. The created binary (gcc3) has been successfully > tested on my G2. Thanks, both patches applied! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From wolfram at the-dreams.de Mon May 30 20:03:39 2011 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 30 May 2011 22:03:39 +0200 Subject: [PATCH 2/2] board: mtk: increase RAM sizes in linker script In-Reply-To: <20110530195222.GF14428@prithivi.gnumonks.org> References: <1306778597-27870-1-git-send-email-wolfram@the-dreams.de> <1306778597-27870-2-git-send-email-wolfram@the-dreams.de> <20110530195222.GF14428@prithivi.gnumonks.org> Message-ID: <4DE3F81B.2020909@the-dreams.de> On 30/05/11 21:52, Harald Welte wrote: > Hi Wolfgang, Ahem ;) > Thanks, both patches applied! Thanks! From drasko.draskovic at gmail.com Mon May 30 21:41:58 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 30 May 2011 23:41:58 +0200 Subject: First OsmocomBB Connection Tests (Unsuccessful) Message-ID: Hi all, I am trying to have some OsmocomBB communication and my procedure is following : 1) I start osmocon with layer1 sw : ./osmocon -p /dev/ttyUSB1 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin It now waits for power on button from the phone 2) In the other terminal I start mobile application : ./mobile -i 127.0.0.1 Copyright (C) 2008-2010 ... Contributions by ... License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. VTY available on port 4247. No Mobile Station defined, creating: MS '1' <000e> sim.c:1206 init SIM client <0005> gsm48_cc.c:61 init Call Control <0001> gsm48_rr.c:4944 init Radio Ressource process <0004> gsm48_mm.c:1220 init Mobility Management process <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:3472 init PLMN process <0003> gsm322.c:3473 init Cell Selection process Mobile '1' initialized, please start phone now! 3) Now I press a "power-on" button on the phone and I have logs comming out on the both terminals. I guess that MS is doing various cell power measurements and trying to discass with near-by cells over controle channels. However, in ./osmocon terminal it finishes like this : $ ./osmocon -p /dev/ttyUSB1 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 81 . got 4 bytes from modem, data looks like: 1b f6 02 00 .... got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(../../target/firmware/board/compal_e88/layer1.compalram.bin): file_size=47700, hdr_len=4, dnload_len=47707 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(): 1023 bytes (1023/47707) handle_write(): 768 bytes (1791/47707) handle_write(): 768 bytes (2559/47707) handle_write(): 768 bytes (3327/47707) ... handle_write(): 768 bytes (44031/47707) handle_write(): 768 bytes (44799/47707) handle_write(): 768 bytes (45567/47707) handle_write(): 768 bytes (46335/47707) handle_write(): 768 bytes (47103/47707) handle_write(): 604 bytes (47707/47707) 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! OSMOCOM Layer 1 (revision osmocon_v0.0.0-884-gd76345a) ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: 2c903414df039b3f ====================================================================== 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 Download Status: 0x0001 DSP API Version: 0x0000 0x0000 Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 LOST 1201! L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=124 PM MEAS: ARFCN=0, 32 dBm at baseband, -105 dBm at RF PM MEAS: ARFCN=0, 32 dBm at baseband, -105 dBm at RF ... PM MEAS: ARFCN=98, 36 dBm at baseband, -101 dBm at RF PM MEAS: ARFCN=99, 39 dBm at baseband, -98 dBm at RF PM MEAS: ARFCN=100, 31 dBm at baseband, -106 dBm at RF PM MEAS: ARFCN=101, 30 dBm at baseband, -107 dBm at RF PM MEAS: ARFCN=110, 36 dBm at baseband, -101 dBm at RF PM MEAS: ARFCN=111, 34 dBm at baseband, -103 dBm at RF PM MEAS: ARFCN=112, 31 dBm at baseband, -107 dBm at RF PM MEAS: ARFCN=113, 33 dBm at baseband, -104 dBm at RF ... L1CTL_PM_REQ start=955 end=1023 PM MEAS: ARFCN=955, 26 dBm at baseband, -111 dBm at RF PM MEAS: ARFCN=955, 26 dBm at baseband, -111 dBm at RF PM MEAS: ARFCN=956, 27 dBm at baseband, -110 dBm at RF PM MEAS: ARFCN=957, 26 dBm at baseband, -111 dBm at RF PM MEAS: ARFCN=958, 27 dBm at baseband, -110 dBm at RF PM MEAS: ARFCN=959, 25 dBm at baseband, -112 dBm at RF ... PM MEAS: ARFCN=1020, 37 dBm at baseband, -100 dBm at RF PM MEAS: ARFCN=1021, 41 dBm at baseband, -96 dBm at RF PM MEAS: ARFCN=1022, 31 dBm at baseband, -106 dBm at RF PM MEAS: ARFCN=1023, 42 dBm at baseband, -95 dBm at RF L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=121, flags=0x7) Starting FCCH RecognitionFB0 (1735:8): TOA= 9600, Power= -52dBm, Angle= 1218Hz FB1 (1745:8): TOA= 9563, Power= -52dBm, Angle= 174Hz fn_offset=1744 (fn=1745 + attempt=8 + ntdma = 7)m delay=9 (fn_offset=1744 + 11 - fn=1745 - 1 scheduling next FB/SB detection task with delay 9 =>FB @ FNR 1744 fn_offset=1744 qbits=3068 Synchronize_TDMA LOST 3054! What would this LOST 3054! say ? It does not sound good anyway, but at this point I am not skilled enough to read OsmocomBB logs. On the other side, in the ./mobile terminal I have something like this : <0002> gsm322.c:3099 (ms 1) Event 'EVENT_SWITCH_ON' for automatic PLMN selection in state 'A0 null' <000d> gsm322.c:1056 SIM is removed <0002> gsm322.c:1057 SIM is removed <0002> gsm322.c:512 new state 'A0 null' -> 'A6 no SIM inserted' <0003> gsm322.c:3319 (ms 1) Event 'EVENT_SWITCH_ON' for Cell selection in state 'C0 null' <0003> gsm322.c:2992 Switch on without SIM. <0003> gsm322.c:541 new state 'C0 null' -> 'C6 any cell selection' <0003> gsm322.c:2405 Getting PM for frequency 0 twice. Overwriting the first! Please fix prim_pm.c <0003> gsm322.c:2416 Found signal (frequency 2 rxlev -105 (5)) <0003> gsm322.c:2416 Found signal (frequency 3 rxlev -106 (4)) <0003> gsm322.c:2416 Found signal (frequency 4 rxlev -86 (24)) <0003> gsm322.c:2416 Found signal (frequency 5 rxlev -68 (42)) <0003> gsm322.c:2416 Found signal (frequency 6 rxlev -86 (24)) ... <0003> gsm322.c:2405 Getting PM for frequency 512 twice. Overwriting the first! Please fix prim_pm.c <0003> gsm322.c:2416 Found signal (frequency 512 rxlev -93 (17)) <0003> gsm322.c:2416 Found signal (frequency 516 rxlev -90 (20)) ... <0003> gsm322.c:2416 Found signal (frequency 1023 rxlev -95 (15)) <0003> gsm322.c:2349 Found 201 frequencies. <0003> gsm322.c:258 Sync to ARFCN=121 rxlev=-54 (No sysinfo yet, ccch mode NONE) <0002> gsm322.c:3099 (ms 1) Event 'EVENT_USER_RESEL' for automatic PLMN selection in state 'A6 no SIM inserted' Can somebody explain me what the hell is happening here ? I am watching all these nice Harald's presentations, like one here : http://www.youtube.com/watch?v=H7rNKZdASBE, but I am not obtaining list of cells like presented to which I can synchronize to. Actually, show cell is giving me : OsmocomBB> show cell 1 arfcn |MCC |MNC |LAC |cell ID|forb.LA|prio |min-db |max-pwr|rx-lev -------+-------+-------+-------+-------+-------+-------+-------+-------+------- OsmocomBB> As you can see, I am pretty much lost here and I would highly appreciate helping hand. Thanks and best regards, Drasko From gianni at scaramanga.co.uk Mon May 30 22:09:23 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 30 May 2011 23:09:23 +0100 Subject: First OsmocomBB Connection Tests (Unsuccessful) In-Reply-To: References: Message-ID: <1306793363.15043.5.camel@deckard> On Mon, 2011-05-30 at 23:41 +0200, Drasko DRASKOVIC wrote: ... > OSMOCOM Layer 1 (revision osmocon_v0.0.0-884-gd76345a) > ====================================================================== > Device ID code: 0xb4fb > Device Version code: 0x0000 > ARM ID code: 0xfff3 > cDSP ID code: 0x0128 > Die ID code: 2c903414df039b3f > ====================================================================== > REG_DPLL=0x2413 > CNTL_ARM_CLK=0xf0a1 > CNTL_CLK=0xff91 > CNTL_RST=0xfff3 > CNTL_ARM_DIV=0xfff9 > ====================================================================== > > > THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!! You might want to compile with transmit support if you expect to be able to make calls and so forth, its explained on the wiki ;) ... > L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=121, flags=0x7) > Starting FCCH RecognitionFB0 (1735:8): TOA= 9600, Power= -52dBm, Angle= 1218Hz > FB1 (1745:8): TOA= 9563, Power= -52dBm, Angle= 174Hz > fn_offset=1744 (fn=1745 + attempt=8 + ntdma = 7)m delay=9 > (fn_offset=1744 + 11 - fn=1745 - 1 > scheduling next FB/SB detection task with delay 9 > =>FB @ FNR 1744 fn_offset=1744 qbits=3068 > Synchronize_TDMA > LOST 3054! > > What would this LOST 3054! say ? It does not sound good anyway, but at > this point I am not skilled enough to read OsmocomBB logs. That's fine/normal. ... > PLMN selection in state 'A6 no SIM inserted' > > > Can somebody explain me what the hell is happening here ? No SIM inserted ;) You have 3 options: 1. Check out sylvain's testing branch for a working on-phone SIM driver 2. Use the SAP interface to a PC/SC smartcard reader with SIM inserted. 3. If you want to use GSM test set instead of real network, use test sim functionality of mobile See the 'sim' commands in mobile vty interface, and also try looking around with enable; configure terminal; ms 1 > I am watching all these nice Harald's presentations, like one here : > http://www.youtube.com/watch?v=H7rNKZdASBE, but I am not obtaining > list of cells like presented to which I can synchronize to. Actually, > show cell is giving me : > > OsmocomBB> show cell 1 > arfcn |MCC |MNC |LAC |cell ID|forb.LA|prio |min-db |max-pwr|rx-lev > -------+-------+-------+-------+-------+-------+-------+-------+-------+------- Should be fine after you solve the two above-mentioned problems. The cell table can be a bit laggy anyway... Sometimes even when everything works it takes a long time to register to the network and I don't get cell info until after that succeeded. > OsmocomBB> > > As you can see, I am pretty much lost here and I would highly > appreciate helping hand. Hope that helps. Gianni From drasko.draskovic at gmail.com Mon May 30 22:24:07 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Tue, 31 May 2011 00:24:07 +0200 Subject: First OsmocomBB Connection Tests (Unsuccessful) In-Reply-To: <1306793363.15043.5.camel@deckard> References: <1306793363.15043.5.camel@deckard> Message-ID: On Tue, May 31, 2011 at 12:09 AM, Gianni Tedesco wrote: >> Synchronize_TDMA >> LOST 3054! >> >> What would this LOST 3054! say ? It does not sound good anyway, but at >> this point I am not skilled enough to read OsmocomBB logs. > > That's fine/normal. OK, good. Sounds scary, though. I would prefer FIND message when things go righth :). > > ... >> PLMN selection in state 'A6 no SIM inserted' >> >> >> Can somebody explain me what the hell is happening here ? > > No SIM inserted ;) > > You have 3 options: > 1. Check out sylvain's testing branch for a working on-phone SIM driver > 2. Use the SAP interface to a PC/SC smartcard reader with SIM inserted. > 3. If you want to use GSM test set instead of real network, use test sim > ? functionality of mobile Hmm.. I was convinced that there was some kind of SIM card simulation implemented in the software and that for basic connection no physical SIM card was needed... So, as I understood, to have a cell attachment and to have some packets exchange I will need to pull Sylvain's branch, as I have no network nor PC/SC SIM card reader... > Hope that helps. Yes indeed. I had no idea what was happening, as I was expecting code from the master branch to be operational. I saw NO SIM warning, but as I told you, I thought that there was a SW SIM simulation implementation somewhere inside protocol stack and that no real SIM card was needed for the basic communication (I just want to see few packets coming down the stack to get idea of data flow, so I can later look at the source code and see how they are processed at each layer). Thanks ! BR, Drasko From gianni at scaramanga.co.uk Mon May 30 22:30:14 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 30 May 2011 23:30:14 +0100 Subject: First OsmocomBB Connection Tests (Unsuccessful) In-Reply-To: References: <1306793363.15043.5.camel@deckard> Message-ID: <1306794614.15043.17.camel@deckard> On Tue, 2011-05-31 at 00:24 +0200, Drasko DRASKOVIC wrote: > On Tue, May 31, 2011 at 12:09 AM, Gianni Tedesco > wrote: > >> Synchronize_TDMA > >> LOST 3054! > >> > >> What would this LOST 3054! say ? It does not sound good anyway, but at > >> this point I am not skilled enough to read OsmocomBB logs. > > > > That's fine/normal. > > OK, good. Sounds scary, though. I would prefer FIND message when > things go righth :). > > > > > > ... > >> PLMN selection in state 'A6 no SIM inserted' > >> > >> > >> Can somebody explain me what the hell is happening here ? > > > > No SIM inserted ;) > > > > You have 3 options: > > 1. Check out sylvain's testing branch for a working on-phone SIM driver > > 2. Use the SAP interface to a PC/SC smartcard reader with SIM inserted. > > 3. If you want to use GSM test set instead of real network, use test sim > > functionality of mobile > > Hmm.. I was convinced that there was some kind of SIM card simulation > implemented in the software and that for basic connection no physical > SIM card was needed... Hrm, for cell_log I don't think you need a SIM but when mobile starts it tries to register with the network which requires a subscription. > So, as I understood, to have a cell attachment and to have some > packets exchange I will need to pull Sylvain's branch, as I have no > network nor PC/SC SIM card reader... Yes, if you want to register on a network, make/receive calls, etc. For just finding cells and catching announcements on the beacon channel, you may be better off starting with cell_log > > Hope that helps. > > Yes indeed. I had no idea what was happening, as I was expecting code > from the master branch to be operational. I saw NO SIM warning, but as > I told you, I thought that there was a SW SIM simulation > implementation somewhere inside protocol stack and that no real SIM > card was needed for the basic communication (I just want to see few > packets coming down the stack to get idea of data flow, so I can later > look at the source code and see how they are processed at each layer). It is more or less operational except for those two caveats: 1. TX disabled by default so that you have to actively *do* something yourself before you can transmit on the air, presumably making it your own legal responsibility (whatever that may mean) 2. Current SIM driver is broken, not sure why sylvains is not merged in master but I have heard reports that even his driver doesn't work for some SIM's. > Thanks ! No probs From drasko.draskovic at gmail.com Mon May 30 22:36:47 2011 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Tue, 31 May 2011 00:36:47 +0200 Subject: First OsmocomBB Connection Tests (Unsuccessful) In-Reply-To: <1306794614.15043.17.camel@deckard> References: <1306793363.15043.5.camel@deckard> <1306794614.15043.17.camel@deckard> Message-ID: On Tue, May 31, 2011 at 12:30 AM, Gianni Tedesco wrote: > On Tue, 2011-05-31 at 00:24 +0200, Drasko DRASKOVIC wrote: >> On Tue, May 31, 2011 at 12:09 AM, Gianni Tedesco >> wrote: >> >> Synchronize_TDMA >> >> LOST 3054! >> >> >> >> What would this LOST 3054! say ? It does not sound good anyway, but at >> >> this point I am not skilled enough to read OsmocomBB logs. >> > >> > That's fine/normal. >> >> OK, good. Sounds scary, though. I would prefer FIND message when >> things go righth :). >> >> >> > >> > ... >> >> PLMN selection in state 'A6 no SIM inserted' >> >> >> >> >> >> Can somebody explain me what the hell is happening here ? >> > >> > No SIM inserted ;) >> > >> > You have 3 options: >> > 1. Check out sylvain's testing branch for a working on-phone SIM driver >> > 2. Use the SAP interface to a PC/SC smartcard reader with SIM inserted. >> > 3. If you want to use GSM test set instead of real network, use test sim >> > ? functionality of mobile >> >> Hmm.. I was convinced that there was some kind of SIM card simulation >> implemented in the software and that for basic connection no physical >> SIM card was needed... > > Hrm, for cell_log I don't think you need a SIM but when mobile starts it > tries to register with the network which requires a subscription. > >> So, as I understood, to have a cell attachment and to have some >> packets exchange I will need to pull Sylvain's branch, as I have no >> network nor PC/SC SIM card reader... > > Yes, if you want to register on a network, make/receive calls, etc. No, no.. I can not start with that - seems too advanced for a beginning... Just a simple connection. The simplest stuff possible. > For > just finding cells and catching announcements on the beacon channel, you > may be better off starting with cell_log Yes great. I'd like to start only with that. So I guess current master is able to do this, I do not need SIM... I prefer to try this for a gentle introduction. > It is more or less operational except for those two caveats: > > 1. TX disabled by default so that you have to actively *do* something > yourself before you can transmit on the air, presumably making it your > own legal responsibility (whatever that may mean) Yes I noticed this one. But as I said, I have no intention to TX anything. Just to receive some signals and to have packet appearing on my host running Wireshark. So, that I can slowly start changing/adding logs to layer1 and layer23 code and observe consequences in educational purposes. > > 2. Current SIM driver is broken, not sure why sylvains is not merged in > master but I have heard reports that even his driver doesn't work for > some SIM's. OK. Great informations. Helps a lot ! BR, Drasko From gianni at scaramanga.co.uk Mon May 30 22:52:41 2011 From: gianni at scaramanga.co.uk (Gianni Tedesco) Date: Mon, 30 May 2011 23:52:41 +0100 Subject: First OsmocomBB Connection Tests (Unsuccessful) In-Reply-To: References: <1306793363.15043.5.camel@deckard> <1306794614.15043.17.camel@deckard> Message-ID: <1306795961.15043.24.camel@deckard> On Tue, 2011-05-31 at 00:36 +0200, Drasko DRASKOVIC wrote: > On Tue, May 31, 2011 at 12:30 AM, Gianni Tedesco > wrote: > > On Tue, 2011-05-31 at 00:24 +0200, Drasko DRASKOVIC wrote: > >> On Tue, May 31, 2011 at 12:09 AM, Gianni Tedesco > >> wrote: > >> >> Synchronize_TDMA > >> >> LOST 3054! > >> >> > >> >> What would this LOST 3054! say ? It does not sound good anyway, but at > >> >> this point I am not skilled enough to read OsmocomBB logs. > >> > > >> > That's fine/normal. > >> > >> OK, good. Sounds scary, though. I would prefer FIND message when > >> things go righth :). > >> > >> > >> > > >> > ... > >> >> PLMN selection in state 'A6 no SIM inserted' > >> >> > >> >> > >> >> Can somebody explain me what the hell is happening here ? > >> > > >> > No SIM inserted ;) > >> > > >> > You have 3 options: > >> > 1. Check out sylvain's testing branch for a working on-phone SIM driver > >> > 2. Use the SAP interface to a PC/SC smartcard reader with SIM inserted. > >> > 3. If you want to use GSM test set instead of real network, use test sim > >> > functionality of mobile > >> > >> Hmm.. I was convinced that there was some kind of SIM card simulation > >> implemented in the software and that for basic connection no physical > >> SIM card was needed... > > > > Hrm, for cell_log I don't think you need a SIM but when mobile starts it > > tries to register with the network which requires a subscription. > > > >> So, as I understood, to have a cell attachment and to have some > >> packets exchange I will need to pull Sylvain's branch, as I have no > >> network nor PC/SC SIM card reader... > > > > Yes, if you want to register on a network, make/receive calls, etc. > No, no.. I can not start with that - seems too advanced for a > beginning... Just a simple connection. The simplest stuff possible. > > > For > > just finding cells and catching announcements on the beacon channel, you > > may be better off starting with cell_log > > Yes great. I'd like to start only with that. So I guess current master > is able to do this, I do not need SIM... > I prefer to try this for a gentle introduction. Should be fine with master with no modifications afaik. Happy hacking! Gianni From laforge at gnumonks.org Tue May 31 06:44:02 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 31 May 2011 08:44:02 +0200 Subject: Meaning of LOST message In-Reply-To: References: Message-ID: <20110531064402.GI14428@prithivi.gnumonks.org> Hi, On Mon, May 30, 2011 at 11:41:58PM +0200, Drasko DRASKOVIC wrote: > LOST 3054! > > What would this LOST 3054! say ? It does not sound good anyway, but at > this point I am not skilled enough to read OsmocomBB logs. This is the output of some code I wrote a while ago in order to detect when our CPU is too busy in the GSM L1 and thus looses one interrupt. When we enter the L1S (synchronouos part of L1) in FIQ mode, further FIQs are disabled and remain disabled until L1S returns from FIQ. If the overall time takes longer than the 4000 quarter-bit-clocks between two TDMA interrupts, then we print that LOST message. However, the LOST detection logic is not 100% perfect, either. So if you see the occasional message here and there it is fine. If you see a sequence of them, I would say it is an indication of a problem. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)