From laforge at gnumonks.org  Wed Nov  2 08:20:36 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 2 Nov 2011 09:20:36 +0100
Subject: [PATCH] SAP client
In-Reply-To: <20110523224725.GA3194@segfault.binarybase.org>
References: <1305072748.25954.4.camel@deckard>
	<1305074358.25954.7.camel@deckard>
	<20110511121208.GA2902@segfault.binarybase.org>
	<20110523072957.GA2139@segfault.binarybase.org>
	<20110523224725.GA3194@segfault.binarybase.org>
Message-ID: <20111102082036.GP6995@prithivi.gnumonks.org>

Hi all,

On Tue, May 24, 2011 at 12:47:25AM +0200, Nico Golde wrote:
> * Nico Golde <osmocom at ngolde.de> [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.

about half a year later, we still have never decided if we want to merge
that patch or not.

There has been some off-list arguments/doubts about whether we want to
route our SIM card accesses to something along the lines of a
BT-SAP-style interface.

The advantage is that we have a clear and somewhat standardized
interface to external applications that provide [remote] SIM card
access or SIM card emulation.

I personally am in favor of the patch, but given that I wasn't involved
in any other SIM related work of OsmocomBB, I feel it is up to other
developers to make any decision.

In case we agree it gets merged, I would like to suggest adding some
comments to the code, in the sense of "why are we doing this", and "what
standard is this oriented at", two topics which are not clear to
somebody who doesn't know the history of the patch before it was merged.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           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  Wed Nov  2 09:17:37 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 2 Nov 2011 10:17:37 +0100
Subject: [PATCH] SAP client
In-Reply-To: <20111102082036.GP6995@prithivi.gnumonks.org>
References: <1305072748.25954.4.camel@deckard>
	<1305074358.25954.7.camel@deckard>
	<20110511121208.GA2902@segfault.binarybase.org>
	<20110523072957.GA2139@segfault.binarybase.org>
	<20110523224725.GA3194@segfault.binarybase.org>
	<20111102082036.GP6995@prithivi.gnumonks.org>
Message-ID: <CAHL+j0_7L2JCp0dVmWWGhn1S+Z6G_QhWtk290EwjEjXcCZY6tQ@mail.gmail.com>

Hi,

> about half a year later, we still have never decided if we want to merge
> that patch or not.

But what does that patch do exacty ?

I think it'd be great if:
 - mobile could use any other card reader
 - any other app could use the onboard sim reader

Does the patch achieves any of these ?

Is there a pcsc -> bt-sap server    bt-sap client -> pcsc  code
available somewhere ?

Cheers,

    Sylvain



From kevredon at mail.tsaitgaist.info  Wed Nov  2 09:29:22 2011
From: kevredon at mail.tsaitgaist.info (Kevin Redon)
Date: Wed, 02 Nov 2011 10:29:22 +0100
Subject: [PATCH] SAP client
In-Reply-To: <CAHL+j0_7L2JCp0dVmWWGhn1S+Z6G_QhWtk290EwjEjXcCZY6tQ@mail.gmail.com>
References: <1305072748.25954.4.camel@deckard>
	<1305074358.25954.7.camel@deckard>
	<20110511121208.GA2902@segfault.binarybase.org>
	<20110523072957.GA2139@segfault.binarybase.org>
	<20110523224725.GA3194@segfault.binarybase.org>
	<20111102082036.GP6995@prithivi.gnumonks.org>
	<CAHL+j0_7L2JCp0dVmWWGhn1S+Z6G_QhWtk290EwjEjXcCZY6tQ@mail.gmail.com>
Message-ID: <1320225970-sup-6901@dennou>

There is already code doing that, using the BT-SAP interface:
http://bb.osmocom.org/trac/wiki/softSIM

it's written in ruby, but it was just for demos purposes and works.
- you can provide a SIM from the PCSC interface
- you can read a SIM using the BT-SAP interface
- you can simulate a SIM (softSIM)
- ...

thanks,
kevin

Excerpte from Sylvain Munaut's message of Wed Nov 02 10:17:37 +0100 2011:
> Hi,
> 
> > about half a year later, we still have never decided if we want to merge
> > that patch or not.
> 
> But what does that patch do exacty ?
> 
> I think it'd be great if:
>  - mobile could use any other card reader
>  - any other app could use the onboard sim reader
> 
> Does the patch achieves any of these ?
> 
> Is there a pcsc -> bt-sap server    bt-sap client -> pcsc  code
> available somewhere ?
> 
> Cheers,
> 
>     Sylvain



From andreas at eversberg.eu  Sat Nov  5 06:23:36 2011
From: andreas at eversberg.eu (jolly)
Date: Sat, 05 Nov 2011 07:23:36 +0100
Subject: [PATCH] SAP client
In-Reply-To: <20111102082036.GP6995@prithivi.gnumonks.org>
References: <1305072748.25954.4.camel@deckard>	<1305074358.25954.7.camel@deckard>	<20110511121208.GA2902@segfault.binarybase.org>	<20110523072957.GA2139@segfault.binarybase.org>	<20110523224725.GA3194@segfault.binarybase.org>
	<20111102082036.GP6995@prithivi.gnumonks.org>
Message-ID: <4EB4D668.8040301@eversberg.eu>

hi nico,

nice work. i like the idea that BTSAP is used by layer23. this was my
intention when i added the sap_interface.c. not only that layer23 can
use softsim as reader, but also other btsap clients could use osmocombb
as reader. to make this possible, the next step would be adding the
btsap server socket to osmocon. (currently it only provides a socket for
L1CTL.) also layer1 sim reader would require to get a btsap compatible
interface.

there is only one thing i disagree: you implemented function in the VTY
to set the socket. this is already done in the configurations of each
mobile instance. i would suggest that you open the socket
(osmosap_init(ms)) at app_mobile.c when the instance is started (no
shutdown), in case the socket is given. then, if the mobile instance
starts working, the socket will be connected and the sim client will
read the sim as soon as the socket is connected.

best regards,

andreas




From osmocom at ngolde.de  Tue Nov  8 15:29:29 2011
From: osmocom at ngolde.de (Nico Golde)
Date: Tue, 8 Nov 2011 16:29:29 +0100
Subject: [PATCH] SAP client
In-Reply-To: <4EB4D668.8040301@eversberg.eu>
References: <1305072748.25954.4.camel@deckard>
	<1305074358.25954.7.camel@deckard>
	<20110511121208.GA2902@segfault.binarybase.org>
	<20110523072957.GA2139@segfault.binarybase.org>
	<20110523224725.GA3194@segfault.binarybase.org>
	<20111102082036.GP6995@prithivi.gnumonks.org>
	<4EB4D668.8040301@eversberg.eu>
Message-ID: <20111108152928.GA26118@segfault.binarybase.org>

Hi,
I'm also in favor for BTSAP. I personally find the protocol 
fairly sane and like Kevin mentioned there is also already 
the SAP server implementation in the osmocom repositories.

* jolly <andreas at eversberg.eu> [2011-11-07 17:31]:
> nice work. i like the idea that BTSAP is used by layer23. this was my
> intention when i added the sap_interface.c. not only that layer23 can
> use softsim as reader, but also other btsap clients could use osmocombb
> as reader.

I didn't even think of this option so far, but it's a good 
idea and shouldn't be too difficult to add to the current 
code!

> to make this possible, the next step would be adding the
> btsap server socket to osmocon. (currently it only provides a socket for
> L1CTL.) also layer1 sim reader would require to get a btsap compatible
> interface.
> 
> there is only one thing i disagree: you implemented function in the VTY
> to set the socket. this is already done in the configurations of each
> mobile instance. i would suggest that you open the socket
> (osmosap_init(ms)) at app_mobile.c when the instance is started (no
> shutdown), in case the socket is given. then, if the mobile instance
> starts working, the socket will be connected and the sim client will
> read the sim as soon as the socket is connected.

I totally agree. I think the reason I did it this way was 
for simplicity because when the reader and the SAP interface 
are activated manually subsequently, the ATR command will already
have it's reply. If it's not done this way the mobile 
application would have to wait for it to complete because 
the process is fairly slow. But the cleaner way would be 
app_mobile.c. I can work on that but will likely need some 
time due to various other commitments at the moment.

Kind regards
Nico



From lonelysurfer at web.de  Tue Nov  8 10:30:44 2011
From: lonelysurfer at web.de (lonelysurfer)
Date: Tue, 8 Nov 2011 02:30:44 -0800 (PST)
Subject: GPRS decode tutorial
In-Reply-To: <CAOYJJftBQ1+TWhVTk2y4fwjHRxGGsOn7Am0jcehg4k9Nq6wV0g@mail.gmail.com>
References: <CAOYJJftBQ1+TWhVTk2y4fwjHRxGGsOn7Am0jcehg4k9Nq6wV0g@mail.gmail.com>
Message-ID: <1320748244767-3489849.post@n3.nabble.com>

another question:
who can I use more than 2 phones?

mo1:
 ./host/osmocon/osmocon -m c123xor -p /dev/ttyUSB0
./target/firmware/board/compal_e88/layer1.compalram.bin
mo2:
 ./host/osmocon/osmocon -m c123xor -p /dev/ttyUSB1
./target/firmware/board/compal_e88/layer1.compalram.bin

If if use only one mobile, ttyUSB0 / ttyUSB1 is working, 
but if I started both at the same time, only one mobile is working.
Same with 2 different firmwares.

How can I set up more phones to get the whole frame / up- and downlink.

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/GPRS-decode-tutorial-tp3437051p3489849.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From 246tnt at gmail.com  Tue Nov  8 10:45:14 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 8 Nov 2011 11:45:14 +0100
Subject: GPRS decode tutorial
In-Reply-To: <1320748244767-3489849.post@n3.nabble.com>
References: <CAOYJJftBQ1+TWhVTk2y4fwjHRxGGsOn7Am0jcehg4k9Nq6wV0g@mail.gmail.com>
	<1320748244767-3489849.post@n3.nabble.com>
Message-ID: <CAHL+j09+anrnekShVyzfnHFHKWmPrTd7mHudYnaQoNq5J38-3A@mail.gmail.com>

> mo1:
>  ./host/osmocon/osmocon -m c123xor -p /dev/ttyUSB0
> ./target/firmware/board/compal_e88/layer1.compalram.bin
> mo2:
>  ./host/osmocon/osmocon -m c123xor -p /dev/ttyUSB1
> ./target/firmware/board/compal_e88/layer1.compalram.bin
>
> If if use only one mobile, ttyUSB0 / ttyUSB1 is working,
> but if I started both at the same time, only one mobile is working.
> Same with 2 different firmwares.
>
> How can I set up more phones to get the whole frame / up- and downlink.

1) You must launch everything twice, including launching ccch_scan (or
layer23 for older version).
2) Look in the command line option of osmocon and ccch_scan, you will
find an option to specify the l2 socket. Each pair of software needs a
different socket.
3) There is a software in the gprs git to then 'combine' both output
in a single file



From lonelysurfer at web.de  Tue Nov  8 12:54:27 2011
From: lonelysurfer at web.de (lonelysurfer)
Date: Tue, 8 Nov 2011 04:54:27 -0800 (PST)
Subject: GPRS decode tutorial
In-Reply-To: <CAHL+j09+anrnekShVyzfnHFHKWmPrTd7mHudYnaQoNq5J38-3A@mail.gmail.com>
References: <CAOYJJftBQ1+TWhVTk2y4fwjHRxGGsOn7Am0jcehg4k9Nq6wV0g@mail.gmail.com>
	<1320748244767-3489849.post@n3.nabble.com>
	<CAHL+j09+anrnekShVyzfnHFHKWmPrTd7mHudYnaQoNq5J38-3A@mail.gmail.com>
Message-ID: <1320756867151-3490176.post@n3.nabble.com>

thank you for your fast reply.
Now both mobiles are working.
For the downlink-frame should I use 2 different firmwares with different
schedulers?



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/GPRS-decode-tutorial-tp3437051p3490176.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From andreas at eversberg.eu  Tue Nov  1 11:28:05 2011
From: andreas at eversberg.eu (jolly)
Date: Tue, 01 Nov 2011 12:28:05 +0100
Subject: delay in SIM reader interrupt handler
Message-ID: <4EAFD7C5.3090100@eversberg.eu>

hi dieter,

i like to clean up and merge the sim reader code with master branch.
while looking at the code i found a delay_ms(1) in interrupt handler:

-------
        /* Used by: calypso_sim_transmit() to transmit the data */
        if(regVal & REG_SIM_IT_SIM_TX)
        {
#if (SIM_DEBUG == 1)
                puts(" Waiting for transmit...\n");
#endif
                if(sim_tx_character_count >= sim_tx_character_length)
                {
                        txDoneFlag = 1;
                }
                else
                {
                        writew(*tx_buffer,REG_SIM_DTX);
                        tx_buffer++;
                        sim_tx_character_count++;

        #if 1 /* Dieter: set to 0 to get problems with some cards */
                        /* its essential to immediately switch to RX
after TX is done */
                        if(sim_tx_character_count >=
sim_tx_character_length)
                        {
                                /* TODO: set a proper delay here, 4 is to
                                   long if not debugging and no delay is
too short */
                                delay_ms(1);
                                /* Switch I/O direction to input */
                                writew(readw(REG_SIM_CONF1) &
~REG_SIM_CONF1_CONFTXRX, REG_SIM_CONF1);
                        }
        #endif
                }
        }
---------

i removed the delay, and it works. i checked the tsm30 source code. it
also sets the IO to input right after writing the last TX byte. (i guess
that the controller will trigger the IO switching at the end of
transmission.) so why do we need that delay? are there any problems?

regards,

andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111101/29c68d87/attachment.htm>

From spaar at mirider.augusta.de  Tue Nov  1 13:07:35 2011
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 01 Nov 2011 13:07:35 
Subject: delay in SIM reader interrupt handler
Message-ID: <4eafef17.mirider@mirider.augusta.de>

Hello Andreas,

On Tue, 01 Nov 2011 12:28:05 +0100, "jolly" <andreas at eversberg.eu> wrote:
> 
> i removed the delay, and it works. i checked the tsm30 source code. it
> also sets the IO to input right after writing the last TX byte. (i guess
> that the controller will trigger the IO switching at the end of
> transmission.) so why do we need that delay? are there any problems?

I can't tell you exactly what went wrong (it was months ago that I
worked on this part). But most certainly one of my Test SIMs did 
not work without this delay. So I would suggest to leave a comment 
at this place in case problems with certain SIMs occur.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From andresbf at gmail.com  Mon Nov  7 13:53:48 2011
From: andresbf at gmail.com (Andres Berroa)
Date: Mon, 7 Nov 2011 09:53:48 -0400
Subject: Pirelli never syncs
Message-ID: <CAPdfEjF1nJHv+_CeTKnx0dymRhJOpEpU1cMOMT2J+H=sEHZxtg@mail.gmail.com>

Hello everybody,

I bought several Pirelli DP-L10.  I checked out the master branch of
Osmocom, changed the console.h and sercomm.h, and enabled the
CONFIG_TX_ENABLE option.  The code compiled successfully.  I loaded the
compiled firmware onto the Pirelli with osmocon, and after it loaded, I ran
cell_log and mobile.  But the phone never syncs to a cell.

I first tried with the "no stick" option. But after this, I tried to find a
strong cell (I used a Blackberry 9300 for this, it has a nice engineering
screen).  I found cells from -76 dbm to -104 dbm.  I tried them all with
the "stick xxx" option, but still, the phone does not sync to this cells.

The last thing I tried was using the binaries a friend provided me.  He
compiled the code on his computer, he tested those binaries at his home,
with his Pirelli, and it worked: he could sync.  He sent me those same
binaries, but still no luck, the phone cannot sync.

I have tried this on 4 different computers, 2 different versions of Ubuntu,
on Debian, and on a Mac.  It doesn't seem it's an operating system problem,
but I wanted to test it anyway.  The only thing it's different from you
it's I live in the Caribbean, but I have GSM networks on all four bands.

Now, if I use my sim on the Pirelli, with the original firmware, it works.
I can even make a call, so I think it's not a hardware problem.  I tested
with Nokia C118 on a 850Mhz network, but same story.

I'm posting my mobile.cfg file, and some logs.

Thank you for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111107/033baf00/attachment.htm>
-------------- next part --------------
# ./cell_log
Copyright (C) 2010 Andreas Eversberg

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000e> cell_log.c:806 Scanner initialized
Mobile initialized, please start phone now!
<000e> cell_log.c:370 Measure from 0 to 2
<000e> cell_log.c:370 Measure from 512 to 606
<000e> cell_log.c:370 Measure from 955 to 956
<000e> cell_log.c:361 Measurement done
<000e> cell_log.c:343 Sync ARFCN 2 (rxlev -91, 103 syncs left)
<000e> cell_log.c:343 Sync ARFCN 604 (rxlev -93, 102 syncs left)
<000e> cell_log.c:343 Sync ARFCN 606 (rxlev -93, 101 syncs left)
<000e> cell_log.c:343 Sync ARFCN 956 (rxlev -93, 100 syncs left)
<000e> cell_log.c:343 Sync ARFCN 0 (rxlev -94, 99 syncs left)
<000e> cell_log.c:343 Sync ARFCN 518 (rxlev -94, 98 syncs left)
<000e> cell_log.c:343 Sync ARFCN 546 (rxlev -94, 97 syncs left)
<000e> cell_log.c:343 Sync ARFCN 552 (rxlev -94, 96 syncs left)
<000e> cell_log.c:343 Sync ARFCN 555 (rxlev -94, 95 syncs left)
<000e> cell_log.c:343 Sync ARFCN 559 (rxlev -94, 94 syncs left)
<000e> cell_log.c:343 Sync ARFCN 561 (rxlev -94, 93 syncs left)
<000e> cell_log.c:343 Sync ARFCN 563 (rxlev -94, 92 syncs left)
<000e> cell_log.c:343 Sync ARFCN 572 (rxlev -94, 91 syncs left)
<000e> cell_log.c:343 Sync ARFCN 573 (rxlev -94, 90 syncs left)
<000e> cell_log.c:343 Sync ARFCN 578 (rxlev -94, 89 syncs left)
<000e> cell_log.c:343 Sync ARFCN 579 (rxlev -94, 88 syncs left)
<000e> cell_log.c:343 Sync ARFCN 580 (rxlev -94, 87 syncs left)
<000e> cell_log.c:343 Sync ARFCN 587 (rxlev -94, 86 syncs left)
<000e> cell_log.c:343 Sync ARFCN 600 (rxlev -94, 85 syncs left)
<000e> cell_log.c:343 Sync ARFCN 515 (rxlev -95, 84 syncs left)
<000e> cell_log.c:343 Sync ARFCN 955 (rxlev -95, 83 syncs left)
<000e> cell_log.c:343 Sync ARFCN 531 (rxlev -96, 82 syncs left)
<000e> cell_log.c:343 Sync ARFCN 586 (rxlev -96, 81 syncs left)
<000e> cell_log.c:343 Sync ARFCN 595 (rxlev -96, 80 syncs left)
<000e> cell_log.c:343 Sync ARFCN 602 (rxlev -96, 79 syncs left)
<000e> cell_log.c:343 Sync ARFCN 1 (rxlev -97, 78 syncs left)
<000e> cell_log.c:343 Sync ARFCN 512 (rxlev -97, 77 syncs left)
<000e> cell_log.c:343 Sync ARFCN 517 (rxlev -97, 76 syncs left)
<000e> cell_log.c:343 Sync ARFCN 519 (rxlev -97, 75 syncs left)
<000e> cell_log.c:343 Sync ARFCN 523 (rxlev -97, 74 syncs left)
<000e> cell_log.c:343 Sync ARFCN 526 (rxlev -97, 73 syncs left)
<000e> cell_log.c:343 Sync ARFCN 527 (rxlev -97, 72 syncs left)
<000e> cell_log.c:343 Sync ARFCN 528 (rxlev -97, 71 syncs left)
<000e> cell_log.c:343 Sync ARFCN 529 (rxlev -97, 70 syncs left)
<000e> cell_log.c:343 Sync ARFCN 533 (rxlev -97, 69 syncs left)
<000e> cell_log.c:343 Sync ARFCN 534 (rxlev -97, 68 syncs left)
<000e> cell_log.c:343 Sync ARFCN 535 (rxlev -97, 67 syncs left)
<000e> cell_log.c:343 Sync ARFCN 536 (rxlev -97, 66 syncs left)
<000e> cell_log.c:343 Sync ARFCN 537 (rxlev -97, 65 syncs left)
<000e> cell_log.c:343 Sync ARFCN 538 (rxlev -97, 64 syncs left)
<000e> cell_log.c:343 Sync ARFCN 540 (rxlev -97, 63 syncs left)
<000e> cell_log.c:343 Sync ARFCN 541 (rxlev -97, 62 syncs left)
<000e> cell_log.c:343 Sync ARFCN 542 (rxlev -97, 61 syncs left)
<000e> cell_log.c:343 Sync ARFCN 544 (rxlev -97, 60 syncs left)
<000e> cell_log.c:343 Sync ARFCN 545 (rxlev -97, 59 syncs left)
<000e> cell_log.c:343 Sync ARFCN 547 (rxlev -97, 58 syncs left)
<000e> cell_log.c:343 Sync ARFCN 549 (rxlev -97, 57 syncs left)
<000e> cell_log.c:343 Sync ARFCN 551 (rxlev -97, 56 syncs left)
<000e> cell_log.c:343 Sync ARFCN 553 (rxlev -97, 55 syncs left)
<000e> cell_log.c:343 Sync ARFCN 554 (rxlev -97, 54 syncs left)
<000e> cell_log.c:343 Sync ARFCN 560 (rxlev -97, 53 syncs left)
<000e> cell_log.c:343 Sync ARFCN 562 (rxlev -97, 52 syncs left)
<000e> cell_log.c:343 Sync ARFCN 564 (rxlev -97, 51 syncs left)
<000e> cell_log.c:343 Sync ARFCN 569 (rxlev -97, 50 syncs left)
<000e> cell_log.c:343 Sync ARFCN 574 (rxlev -97, 49 syncs left)
<000e> cell_log.c:343 Sync ARFCN 576 (rxlev -97, 48 syncs left)
<000e> cell_log.c:343 Sync ARFCN 577 (rxlev -97, 47 syncs left)
<000e> cell_log.c:343 Sync ARFCN 584 (rxlev -97, 46 syncs left)
<000e> cell_log.c:343 Sync ARFCN 591 (rxlev -97, 45 syncs left)
<000e> cell_log.c:343 Sync ARFCN 601 (rxlev -97, 44 syncs left)
<000e> cell_log.c:343 Sync ARFCN 603 (rxlev -97, 43 syncs left)
<000e> cell_log.c:343 Sync ARFCN 605 (rxlev -97, 42 syncs left)
<000e> cell_log.c:343 Sync ARFCN 513 (rxlev -98, 41 syncs left)
<000e> cell_log.c:343 Sync ARFCN 514 (rxlev -98, 40 syncs left)
<000e> cell_log.c:343 Sync ARFCN 516 (rxlev -98, 39 syncs left)
<000e> cell_log.c:343 Sync ARFCN 520 (rxlev -98, 38 syncs left)
<000e> cell_log.c:343 Sync ARFCN 521 (rxlev -98, 37 syncs left)
<000e> cell_log.c:343 Sync ARFCN 522 (rxlev -98, 36 syncs left)
<000e> cell_log.c:343 Sync ARFCN 524 (rxlev -98, 35 syncs left)
<000e> cell_log.c:343 Sync ARFCN 525 (rxlev -98, 34 syncs left)
<000e> cell_log.c:343 Sync ARFCN 530 (rxlev -98, 33 syncs left)
<000e> cell_log.c:343 Sync ARFCN 532 (rxlev -98, 32 syncs left)
<000e> cell_log.c:343 Sync ARFCN 539 (rxlev -98, 31 syncs left)
<000e> cell_log.c:343 Sync ARFCN 543 (rxlev -98, 30 syncs left)
<000e> cell_log.c:343 Sync ARFCN 548 (rxlev -98, 29 syncs left)
<000e> cell_log.c:343 Sync ARFCN 550 (rxlev -98, 28 syncs left)
<000e> cell_log.c:343 Sync ARFCN 556 (rxlev -98, 27 syncs left)
<000e> cell_log.c:343 Sync ARFCN 557 (rxlev -98, 26 syncs left)
<000e> cell_log.c:343 Sync ARFCN 558 (rxlev -98, 25 syncs left)
<000e> cell_log.c:343 Sync ARFCN 565 (rxlev -98, 24 syncs left)
<000e> cell_log.c:343 Sync ARFCN 566 (rxlev -98, 23 syncs left)
<000e> cell_log.c:343 Sync ARFCN 567 (rxlev -98, 22 syncs left)
<000e> cell_log.c:343 Sync ARFCN 568 (rxlev -98, 21 syncs left)
<000e> cell_log.c:343 Sync ARFCN 570 (rxlev -98, 20 syncs left)
<000e> cell_log.c:343 Sync ARFCN 575 (rxlev -98, 19 syncs left)
<000e> cell_log.c:343 Sync ARFCN 581 (rxlev -98, 18 syncs left)
<000e> cell_log.c:343 Sync ARFCN 582 (rxlev -98, 17 syncs left)
<000e> cell_log.c:343 Sync ARFCN 583 (rxlev -98, 16 syncs left)
<000e> cell_log.c:343 Sync ARFCN 585 (rxlev -98, 15 syncs left)
<000e> cell_log.c:343 Sync ARFCN 588 (rxlev -98, 14 syncs left)
<000e> cell_log.c:343 Sync ARFCN 589 (rxlev -98, 13 syncs left)
<000e> cell_log.c:343 Sync ARFCN 590 (rxlev -98, 12 syncs left)
<000e> cell_log.c:343 Sync ARFCN 592 (rxlev -98, 11 syncs left)
<000e> cell_log.c:343 Sync ARFCN 593 (rxlev -98, 10 syncs left)
<000e> cell_log.c:343 Sync ARFCN 594 (rxlev -98, 9 syncs left)
<000e> cell_log.c:343 Sync ARFCN 596 (rxlev -98, 8 syncs left)
<000e> cell_log.c:343 Sync ARFCN 597 (rxlev -98, 7 syncs left)
<000e> cell_log.c:343 Sync ARFCN 598 (rxlev -98, 6 syncs left)
<000e> cell_log.c:343 Sync ARFCN 599 (rxlev -98, 5 syncs left)
<000e> cell_log.c:343 Sync ARFCN 571 (rxlev -99, 4 syncs left)
<000e> cell_log.c:370 Measure from 0 to 2
<000e> cell_log.c:370 Measure from 512 to 606

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mobile.cfg
Type: application/octet-stream
Size: 906 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111107/033baf00/attachment.obj>
-------------- next part --------------
# ./osmocon -p /dev/ttyUSB3 -m romload ../../target/firmware/board/pirelli_dpl10/layer1.highram.bin
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
Sending Calypso romloader beacon...
got 2 bytes from modem, data looks like: 3e 69  >i
Received ident ack from phone, sending parameter sequence
read_file(../../target/firmware/board/pirelli_dpl10/layer1.highram.bin): file_size=50740, hdr_len=0, dnload_len=50743
Received parameter ack from phone, starting download
Used blocksize for download is 1024 bytes
Preparing block 1, block checksum is 0x82 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 1 finished
Received block ack from phone
Preparing block 2, block checksum is 0x6c 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 2 finished
Received block ack from phone
Preparing block 3, block checksum is 0x5e 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 3 finished
Received block ack from phone
Preparing block 4, block checksum is 0x2c 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 4 finished
Received block ack from phone
Preparing block 5, block checksum is 0x54 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 5 finished
Received block ack from phone
Preparing block 6, block checksum is 0xd7 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 6 finished
Received block ack from phone
Preparing block 7, block checksum is 0x77 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 7 finished
Received block ack from phone
Preparing block 8, block checksum is 0x16 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 8 finished
Received block ack from phone
Preparing block 9, block checksum is 0x1a 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 9 finished
Received block ack from phone
Preparing block 10, block checksum is 0x08 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 10 finished
Received block ack from phone
Preparing block 11, block checksum is 0x8a 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 11 finished
Received block ack from phone
Preparing block 12, block checksum is 0x4b 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 12 finished
Received block ack from phone
Preparing block 13, block checksum is 0x51 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 13 finished
Received block ack from phone
Preparing block 14, block checksum is 0x68 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 14 finished
Received block ack from phone
Preparing block 15, block checksum is 0xc8 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 15 finished
Received block ack from phone
Preparing block 16, block checksum is 0x46 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 16 finished
Received block ack from phone
Preparing block 17, block checksum is 0x16 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 17 finished
Received block ack from phone
Preparing block 18, block checksum is 0xec 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 18 finished
Received block ack from phone
Preparing block 19, block checksum is 0x90 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 19 finished
Received block ack from phone
Preparing block 20, block checksum is 0x6f 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 20 finished
Received block ack from phone
Preparing block 21, block checksum is 0x67 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 21 finished
Received block ack from phone
Preparing block 22, block checksum is 0xc1 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 22 finished
Received block ack from phone
Preparing block 23, block checksum is 0x9f 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 23 finished
Received block ack from phone
Preparing block 24, block checksum is 0xf5 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 24 finished
Received block ack from phone
Preparing block 25, block checksum is 0x89 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 25 finished
Received block ack from phone
Preparing block 26, block checksum is 0xe5 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 26 finished
Received block ack from phone
Preparing block 27, block checksum is 0x1e 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 27 finished
Received block ack from phone
Preparing block 28, block checksum is 0x53 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 28 finished
Received block ack from phone
Preparing block 29, block checksum is 0xa3 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 29 finished
Received block ack from phone
Preparing block 30, block checksum is 0x30 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 30 finished
Received block ack from phone
Preparing block 31, block checksum is 0x9b 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 31 finished
Received block ack from phone
Preparing block 32, block checksum is 0x30 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 32 finished
Received block ack from phone
Preparing block 33, block checksum is 0xe2 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 33 finished
Received block ack from phone
Preparing block 34, block checksum is 0x71 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 34 finished
Received block ack from phone
Preparing block 35, block checksum is 0x4b 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 35 finished
Received block ack from phone
Preparing block 36, block checksum is 0xc6 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 36 finished
Received block ack from phone
Preparing block 37, block checksum is 0x97 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 37 finished
Received block ack from phone
Preparing block 38, block checksum is 0x28 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 38 finished
Received block ack from phone
Preparing block 39, block checksum is 0xd0 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 39 finished
Received block ack from phone
Preparing block 40, block checksum is 0xdb 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 40 finished
Received block ack from phone
Preparing block 41, block checksum is 0x0c 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 41 finished
Received block ack from phone
Preparing block 42, block checksum is 0x13 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 42 finished
Received block ack from phone
Preparing block 43, block checksum is 0xf7 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 43 finished
Received block ack from phone
Preparing block 44, block checksum is 0x3e 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 44 finished
Received block ack from phone
Preparing block 45, block checksum is 0x58 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 45 finished
Received block ack from phone
Preparing block 46, block checksum is 0x46 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 46 finished
Received block ack from phone
Preparing block 47, block checksum is 0xe8 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 47 finished
Received block ack from phone
Preparing block 48, block checksum is 0x86 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 48 finished
Received block ack from phone
Preparing block 49, block checksum is 0x88 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 49 finished
Received block ack from phone
Preparing block 50, block checksum is 0x38 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 50 finished
Received block ack from phone
Preparing the last block, filling 974 bytes, block checksum is 0x5e 
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 51 finished
Finished, sent 51 blocks in total
Received block ack from phone
Sending checksum: 0x8b 
Checksum on phone side matches, let's branch to your code
Branching to 0x00820000
Received branch ack, your code is running now!


OSMOCOM Layer 1 (revision osmocon_v0.0.0-1145-g02d469a-modified)
======================================================================
Device ID code: 0xb496
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: e4940d25e494551d
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
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 7282!
L1CTL_RESET_REQ: FULL!L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=2
PM MEAS: ARFCN=0, 44   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=0, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=1, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=2, 46   dBm at baseband, -91  dBm at RF
L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=512 end=606
PM MEAS: ARFCN=512, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=512, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=513, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=514, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=515, 43   dBm at baseband, -95  dBm at RF
PM MEAS: ARFCN=516, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=517, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=518, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=519, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=520, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=521, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=522, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=523, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=524, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=525, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=526, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=527, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=528, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=529, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=530, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=531, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=532, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=533, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=534, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=535, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=536, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=537, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=538, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=539, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=540, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=541, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=542, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=543, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=544, 41   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=545, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=546, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=547, 41   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=548, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=549, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=550, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=551, 41   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=552, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=553, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=554, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=555, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=556, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=557, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=558, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=559, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=560, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=561, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=562, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=563, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=564, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=565, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=566, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=567, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=568, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=569, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=570, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=571, 38   dBm at baseband, -99  dBm at RF
PM MEAS: ARFCN=572, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=573, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=574, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=575, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=576, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=577, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=578, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=579, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=580, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=581, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=582, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=583, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=584, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=585, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=586, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=587, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=588, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=589, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=590, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=591, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=592, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=593, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=594, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=595, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=596, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=597, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=598, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=599, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=600, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=601, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=602, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=603, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=604, 44   dBm at baseband, -93  dBm at RF
PM MEAS: ARFCN=605, 41   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=606, 44   dBm at baseband, -93  dBm at RF
L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=955 end=956
PM MEAS: ARFCN=955, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=955, 42   dBm at baseband, -95  dBm at RF
PM MEAS: ARFCN=956, 44   dBm at baseband, -93  dBm at RF
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=2, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=604, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=956, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=0, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=518, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=546, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=552, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=555, flags=0x7)
Starting FCCH RecognitionLOST 1885!
LOST 1865!
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=559, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=561, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=563, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=572, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=573, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=578, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=579, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=580, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=587, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=600, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=955, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=531, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=586, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=595, flags=0x7)
Starting FCCH RecognitionFB0	(4228:1): TOA=  336, Power=-103dBm, Angle=-22989Hz, SNR=030f(0.382) OFFSET=607 SYNCHRO=607
	FB0	(4232:2): TOA= 1152, Power=-103dBm, Angle=-16217Hz, SNR=0376(0.432) OFFSET=607 SYNCHRO=607
	FB0	(4235:1): TOA=   96, Power=-103dBm, Angle=-12340Hz, SNR=039b(0.450) OFFSET=607 SYNCHRO=607
	FB0	(4239:2): TOA= 1632, Power=-104dBm, Angle=-8312Hz, SNR=040f(1.7) OFFSET=607 SYNCHRO=607
	FB0	(4256:1): TOA=   48, Power=-104dBm, Angle=-5220Hz, SNR=05c7(1.222) OFFSET=607 SYNCHRO=607
	FB0	(4273:1): TOA=  144, Power=-103dBm, Angle=-5278Hz, SNR=044a(1.36) OFFSET=607 SYNCHRO=607
	FB0	(4290:1): TOA=  144, Power=-103dBm, Angle=-6025Hz, SNR=039f(0.452) OFFSET=607 SYNCHRO=607
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=602, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=1, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=512, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=517, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=519, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=523, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=526, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=527, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=528, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=529, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=533, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=534, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=535, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=536, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=537, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=538, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=540, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=541, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=542, flags=0x7)
Starting FCCH RecognitionLOST 1882!
LOST 1868!
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=544, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=545, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=547, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=549, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=551, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=553, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=554, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=560, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=562, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=564, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=569, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=574, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=576, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=577, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=584, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=591, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=601, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=603, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=605, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=513, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=514, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=516, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=520, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=521, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=522, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=524, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=525, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=530, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=532, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=539, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=543, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=548, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=550, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=556, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=557, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=558, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=565, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=566, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=567, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=568, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=570, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=575, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=581, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=582, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=583, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=585, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=588, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=589, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=590, flags=0x7)
Starting FCCH RecognitionLOST 1882!
LOST 1868!
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=592, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=593, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=594, flags=0x7)
Starting FCCH RecognitionFB0	(8474:7): TOA= 8064, Power=-105dBm, Angle=-11342Hz, SNR=032c(0.396) OFFSET=607 SYNCHRO=607
	FB0	(8499:9): TOA= 9792, Power=-106dBm, Angle=-9351Hz, SNR=02fc(0.373) OFFSET=607 SYNCHRO=607
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=596, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=597, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=598, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=599, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=571, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=2
PM MEAS: ARFCN=0, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=0, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=1, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=2, 42   dBm at baseband, -95  dBm at RF
L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=512 end=606
PM MEAS: ARFCN=512, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=512, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=513, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=514, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=515, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=516, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=517, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=518, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=519, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=520, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=521, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=522, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=523, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=524, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=525, 43   dBm at baseband, -95  dBm at RF
PM MEAS: ARFCN=526, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=527, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=528, 43   dBm at baseband, -95  dBm at RF
PM MEAS: ARFCN=529, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=530, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=531, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=532, 38   dBm at baseband, -99  dBm at RF
PM MEAS: ARFCN=533, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=534, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=535, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=536, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=537, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=538, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=539, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=540, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=541, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=542, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=543, 44   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=544, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=545, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=546, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=547, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=548, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=549, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=550, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=551, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=552, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=553, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=554, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=555, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=556, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=557, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=558, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=559, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=560, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=561, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=562, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=563, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=564, 42   dBm at baseband, -95  dBm at RF
PM MEAS: ARFCN=565, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=566, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=567, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=568, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=569, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=570, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=571, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=572, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=573, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=574, 42   dBm at baseband, -95  dBm at RF
PM MEAS: ARFCN=575, 40   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=576, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=577, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=578, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=579, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=580, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=581, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=582, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=583, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=584, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=585, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=586, 38   dBm at baseband, -99  dBm at RF
PM MEAS: ARFCN=587, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=588, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=589, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=590, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=591, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=592, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=593, 43   dBm at baseband, -94  dBm at RF
PM MEAS: ARFCN=594, 38   dBm at baseband, -99  dBm at RF
PM MEAS: ARFCN=595, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=596, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=597, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=598, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=599, 39   dBm at baseband, -98  dBm at RF
PM MEAS: ARFCN=600, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=601, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=602, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=603, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=604, 41   dBm at baseband, -96  dBm at RF
PM MEAS: ARFCN=605, 40   dBm at baseband, -97  dBm at RF
PM MEAS: ARFCN=606, 40   dBm at baseband, -97  dBm at RF


From andresbf at gmail.com  Mon Nov  7 16:08:23 2011
From: andresbf at gmail.com (Andres Berroa)
Date: Mon, 7 Nov 2011 12:08:23 -0400
Subject: Pirelli never syncs
In-Reply-To: <CAHL+j0-5xby-cBqUaUTK3y-H6_4cMyMF+Q0obF1pF2V6ggip=w@mail.gmail.com>
References: <CAPdfEjF1nJHv+_CeTKnx0dymRhJOpEpU1cMOMT2J+H=sEHZxtg@mail.gmail.com>
	<CAHL+j0-5xby-cBqUaUTK3y-H6_4cMyMF+Q0obF1pF2V6ggip=w@mail.gmail.com>
Message-ID: <CAPdfEjHTqHANLwfJjhdvs_fM9rx0JbnLkQfxj3w1VdChOTOJtA@mail.gmail.com>

I'm trying to sync to the 1800 or the 900 bands with the Pirelli, I'm not
using 850/1900.

I tried ccch_scan with different cells.  I attached the logs.




On Mon, Nov 7, 2011 at 11:48 AM, Sylvain Munaut <246tnt at gmail.com> wrote:

> > The only thing it's different from you it's
> > I live in the Caribbean, but I have GSM networks on all four bands.
>
> And what band are you trying to sync to ? And with which hardware ?
>
> The ARFCN of PCS and DCS are overlapped and so I have no idea how
> 'mobile' behaves in that case.
>
> You can try the ccch_scan binary with the -a option to force going to
> a cell and just see if the bcch sync works at all.
> (for PCS ARFCN you have to add 32768 to the arfcn number).
>
> Cheers,
>
>    Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111107/5de68251/attachment.htm>
-------------- next part --------------
OSMOCOM Layer 1 (revision osmocon_v0.0.0-1145-g02d469a-modified)
======================================================================
Device ID code: 0xb496
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: e4940d25e494551d
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
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 1109!
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=595, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=598, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=600, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=595, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=602, flags=0x7)
Starting FCCH Recognition 
	FB0 (135726:1): TOA=  336, Power=-104dBm, Angle=-24665Hz
	FB0 (135729:1): TOA=  288, Power=-103dBm, Angle=-17109Hz
	FB0 (135732:1): TOA=  144, Power=-102dBm, Angle=-12297Hz
	FB0 (135735:1): TOA=   48, Power=-102dBm, Angle=-8667Hz
	FB0 (135752:1): TOA=   96, Power=-103dBm, Angle=-6546Hz
	FB0 (135769:1): TOA=  240, Power=-102dBm, Angle=-5441Hz
L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=600, flags=0x7)
Starting FCCH RecognitionL1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=602, flags=0x7)
Starting FCCH Recognition

-------------- next part --------------
# ./ccch_scan -a 598
Copyright (C) 2010 Harald Welte <laforge at gnumonks.org>
Contributions by Holger Hans Peter Freyther

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000c> l1ctl.c:118 FBSB RESP: result=255
/* ******************************************************************* */
# ./ccch_scan -a 604
Copyright (C) 2010 Harald Welte <laforge at gnumonks.org>
Contributions by Holger Hans Peter Freyther

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000c> l1ctl.c:118 FBSB RESP: result=255
/* ******************************************************************* */
# ./ccch_scan -a 602
Copyright (C) 2010 Harald Welte <laforge at gnumonks.org>
Contributions by Holger Hans Peter Freyther

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000c> l1ctl.c:118 FBSB RESP: result=255
/* ******************************************************************* */
# ./ccch_scan -a 592
Copyright (C) 2010 Harald Welte <laforge at gnumonks.org>
Contributions by Holger Hans Peter Freyther

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000c> l1ctl.c:118 FBSB RESP: result=255
/* ******************************************************************* */
# ./ccch_scan -a 600
Copyright (C) 2010 Harald Welte <laforge at gnumonks.org>
Contributions by Holger Hans Peter Freyther

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000c> l1ctl.c:118 FBSB RESP: result=255
/* ******************************************************************* */
# ./ccch_scan -a 602
Copyright (C) 2010 Harald Welte <laforge at gnumonks.org>
Contributions by Holger Hans Peter Freyther

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000c> l1ctl.c:118 FBSB RESP: result=255
/* ******************************************************************* */
# ./ccch_scan -a 594
Copyright (C) 2010 Harald Welte <laforge at gnumonks.org>
Contributions by Holger Hans Peter Freyther

License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

<000c> l1ctl.c:118 FBSB RESP: result=255


From lonelysurfer at web.de  Tue Nov  8 05:03:36 2011
From: lonelysurfer at web.de (lonelysurfer)
Date: Mon, 7 Nov 2011 21:03:36 -0800 (PST)
Subject: cp2102 (betemcu, B75937)
Message-ID: <1320728616815-3489323.post@n3.nabble.com>

...a never ending story: i have a working ftdi-ttl, but the cp2102-adapters
(http://www.ebay.de/itm/USB-2-0-to-TTL-UART-6PIN-CP2102-Module-Serial-Converter-/260887131702?pt=LH_DefaultDomain_0&hash=item3cbe15b636)
with the same cable dont work under ubuntu or windows. if i rub the top of
the 2.55mm with my finger random data appears. but the loader doesnt upload
the firmware. i used the txd, rxd and gnd pins and checked the connections
with a multimeter. i tested -m c123xor, -m c123 and the default firmware.
flashing custom baudrates was no problem. drivers are installed correctly
(stady ttyusb0 under ubuntu/ com1 under win). is there any hint?

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489323p3489323.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From lonelysurfer at web.de  Tue Nov  8 05:11:35 2011
From: lonelysurfer at web.de (lonelysurfer)
Date: Mon, 7 Nov 2011 21:11:35 -0800 (PST)
Subject: cp2102 (betemcu, B75937)
Message-ID: <1320729095748-3489336.post@n3.nabble.com>

...a never ending story: 
i have a working ftdi-ttl, but the cp2102-adapters 
(http://www.ebay.de/itm/USB-2-0-to-UART-TTL-6PIN-Module-Serial-Converter-CP2102-/370532286388?pt=PCC_Drives_Storage_Internal&hash=item564571ffb4) 
with the same cable dont work under ubuntu or windows. 
if i rub the top of the 2.55mm with my finger random data appears. but the
loader doesnt upload the firmware. 
i used the txd, rxd and gnd pins and checked the connections with a
multimeter. 
i tested -m c123xor, -m c123 and the default firmware. flashing custom
baudrates was no problem. 
rivers are installed correctly (stady ttyusb0 under ubuntu/ com1 under win).
is there any hint? 

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489336p3489336.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From lonelysurfer at web.de  Tue Nov  8 06:18:45 2011
From: lonelysurfer at web.de (lonelysurfer)
Date: Mon, 7 Nov 2011 22:18:45 -0800 (PST)
Subject: cp2102 (betemcu, B75937)
In-Reply-To: <1320729095748-3489336.post@n3.nabble.com>
References: <1320729095748-3489336.post@n3.nabble.com>
Message-ID: <1320733125251-3489415.post@n3.nabble.com>

i checked the silicon laboratories documentation of the cp2102 and i noticed
that the TXD- and RXD-pins are interchanged. TXD and RXD are wrong
labeled!!!
After correcting this these cp2102-adapters are working :-)



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489336p3489415.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From rm.engineer84 at gmail.com  Tue Nov  8 17:27:50 2011
From: rm.engineer84 at gmail.com (R M)
Date: Tue, 8 Nov 2011 22:57:50 +0530
Subject: cp2102 (betemcu, B75937)
In-Reply-To: <1320733125251-3489415.post@n3.nabble.com>
References: <1320729095748-3489336.post@n3.nabble.com>
	<1320733125251-3489415.post@n3.nabble.com>
Message-ID: <CADKJHGYToL21zhfYPEqMPr+W7E3_tksQ4GYMFK66XtbPVucmfg@mail.gmail.com>

Hello,

Did it work on the Windows machine?

I am also using a windows box for running Osmocombb.

My machine is a DELL Vostro 3500 and has an i3 processor.

I am running Windows 7 64 bit. I am using cygwin for compilation.

I am facing timing issues.  I am able to download the Hello World code
just once in 10 tries.

Rest of the 9 times I get ftmtool error.

I am using the ftdi cable mentioned in the wiki.

My cable is a bit long, its about 2 meters.

Is this a cause of the issue?

I downloaded the drivers from the FTDI site.

My laptop has a in-built webcam. This web cam is hard wired to the usb hub.

I ran USBView provided by FTDI.This tool lists all the devices
connected to the usb bus.

 It shows that the FTDI usb serial converter is also connected to the
same usb hub as the inbuilt web cam.

I have not turned on the web cam though.

Does this thing slow down the usb bus even if the web cam is not turned on?

I have even tried to shut down all the unwanted process but still the
same thing. There is no improvement.

I have tried to change the latency timer from the default 16ms to 4ms.
Still no results.

I have commented out the printf statements like

Received 1 byte from modem....

Still there is no improvement.

I have also tried other suggestions suggested by steve in the mailing
list archives for timing issues.

Still no luck.

Can you please let me know what is your machine configuration ?

Are you using cywin or mingw for compiling ?
(I am asking this because you said you used com1 on a windows box.)

Are you also facing timing issues ? How did you resolve your timing issues?

Regards,
RM

On Tue, Nov 8, 2011 at 11:48 AM, lonelysurfer <lonelysurfer at web.de> wrote:
> i checked the silicon laboratories documentation of the cp2102 and i noticed
> that the TXD- and RXD-pins are interchanged. TXD and RXD are wrong
> labeled!!!
> After correcting this these cp2102-adapters are working :-)
>
>
>
> --
> View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489336p3489415.html
> Sent from the baseband-devel mailing list archive at Nabble.com.
>
>



From lonelysurfer at web.de  Tue Nov  8 20:25:00 2011
From: lonelysurfer at web.de (lonelysurfer)
Date: Tue, 8 Nov 2011 12:25:00 -0800 (PST)
Subject: cp2102 (betemcu, B75937)
In-Reply-To: <CADKJHGYToL21zhfYPEqMPr+W7E3_tksQ4GYMFK66XtbPVucmfg@mail.gmail.com>
References: <1320729095748-3489336.post@n3.nabble.com>
	<1320733125251-3489415.post@n3.nabble.com>
	<CADKJHGYToL21zhfYPEqMPr+W7E3_tksQ4GYMFK66XtbPVucmfg@mail.gmail.com>
Message-ID: <1320783900136-3491473.post@n3.nabble.com>

under Win I only used unlocking and flashing tools to check my hardware :-(
There my ftdi is only working with this timing-changes:
(sorry, only in german) 
Ger?temanger - USB Serial Port (ComX) - Anschlusseinstellungen - Erweitert : 
BM Einstellungen von 16ms auf 8ms

Perhaps this setting is working for you too.



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489336p3491473.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From jayrworthington at gmail.com  Tue Nov  8 21:01:26 2011
From: jayrworthington at gmail.com (Jay R. Worthington)
Date: Tue, 8 Nov 2011 22:01:26 +0100
Subject: Sony J120?
Message-ID: <CAB9sg6Nw61AO79j4HgP_gcqX2oS53Wh3DB9NZCnCsb9KLV14Vg@mail.gmail.com>

Hi 'yall,

before i break out the soldering iron, has someone already tried the J120?
It seem's to be a tad newer version of the J100, but with an (FM-) Radio,
the specs lists it as Calypso Chipset...

Regards,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111108/141da0c5/attachment.htm>

From sefaj at generalstudio.ch  Thu Nov 10 13:37:19 2011
From: sefaj at generalstudio.ch (Lorik Sefaj)
Date: Thu, 10 Nov 2011 14:37:19 +0100
Subject: c1xx with filter re-work
Message-ID: <CACsma44WYBUiY3OEHZsv5NsC5cx00v6kUobCjvXKB63hS=P4aQ@mail.gmail.com>

Hi all,
Considering my soldering skills and the fact that I just ruined a c123
trying to replace the filters (which was working perfectly with patched
burst_ind and got me a lot of downlink traffic to work with).

Anyways without wasting your time my question is: does anybody have a c1xx
with filter re-work for sale?

I'd like to get some uplink traffic

Thanks a lot and keep up the great work,
J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111110/084dae9a/attachment.htm>

From 246tnt at gmail.com  Thu Nov 10 14:18:38 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 10 Nov 2011 15:18:38 +0100
Subject: c1xx with filter re-work
In-Reply-To: <CACsma44WYBUiY3OEHZsv5NsC5cx00v6kUobCjvXKB63hS=P4aQ@mail.gmail.com>
References: <CACsma44WYBUiY3OEHZsv5NsC5cx00v6kUobCjvXKB63hS=P4aQ@mail.gmail.com>
Message-ID: <CAHL+j092E07DhwSHWXMHqTTsK_7BVj0xs7+nmu++CKKp4+yxVg@mail.gmail.com>

Hi,

> Considering my soldering skills and the fact that?I just ruined a c123
> trying to replace the filters (which was working perfectly with patched
> burst_ind and got me a lot of downlink traffic to work with).
>
> Anyways without?wasting your time my?question?is: does anybody have a c1xx
> with filter re-work for sale?

See http://shop.sysmocom.de/

Cheers,

    Sylvain



From sefaj at generalstudio.ch  Thu Nov 10 14:40:12 2011
From: sefaj at generalstudio.ch (Lorik Sefaj)
Date: Thu, 10 Nov 2011 15:40:12 +0100
Subject: c1xx with filter re-work
In-Reply-To: <CAHL+j092E07DhwSHWXMHqTTsK_7BVj0xs7+nmu++CKKp4+yxVg@mail.gmail.com>
References: <CACsma44WYBUiY3OEHZsv5NsC5cx00v6kUobCjvXKB63hS=P4aQ@mail.gmail.com>
	<CAHL+j092E07DhwSHWXMHqTTsK_7BVj0xs7+nmu++CKKp4+yxVg@mail.gmail.com>
Message-ID: <CACsma45GO10jGDPNLH=8Z6N9einBcGQJMD=y-3M30jqi8UqhAA@mail.gmail.com>

hehe "out of stock"

but thanks anyways
J

On Thu, Nov 10, 2011 at 3:18 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

> Hi,
>
> > Considering my soldering skills and the fact that I just ruined a c123
> > trying to replace the filters (which was working perfectly with patched
> > burst_ind and got me a lot of downlink traffic to work with).
> >
> > Anyways without wasting your time my question is: does anybody have a
> c1xx
> > with filter re-work for sale?
>
> See http://shop.sysmocom.de/
>
> Cheers,
>
>    Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111110/832c4795/attachment.htm>

From laforge at gnumonks.org  Thu Nov 10 15:51:39 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 10 Nov 2011 16:51:39 +0100
Subject: c1xx with filter re-work
In-Reply-To: <CACsma45GO10jGDPNLH=8Z6N9einBcGQJMD=y-3M30jqi8UqhAA@mail.gmail.com>
References: <CACsma44WYBUiY3OEHZsv5NsC5cx00v6kUobCjvXKB63hS=P4aQ@mail.gmail.com>
	<CAHL+j092E07DhwSHWXMHqTTsK_7BVj0xs7+nmu++CKKp4+yxVg@mail.gmail.com>
	<CACsma45GO10jGDPNLH=8Z6N9einBcGQJMD=y-3M30jqi8UqhAA@mail.gmail.com>
Message-ID: <5ac2cc31-0b35-46da-a8e7-4afdc1d5c517@email.android.com>

we could provide one as early as next week. the price is high as there is a lot of time spent in re-soldering.
--
Sent from a mobile device, excuse my short response

Lorik Sefaj <sefaj at generalstudio.ch> wrote:

hehe "out of stock"

 

but thanks anyways

J

On Thu, Nov 10, 2011 at 3:18 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

Hi,


> Considering my soldering skills and the fact that I just ruined a c123
> trying to replace the filters (which was working perfectly with patched
> burst_ind and got me a lot of downlink traffic to work with).
>
> Anyways without wasting your time my question is: does anybody have a c1xx
> with filter re-work for sale?

See http://shop.sysmocom.de/

Cheers,

   Sylvain


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111110/24013fe4/attachment.htm>

From sefaj at generalstudio.ch  Thu Nov 10 16:00:48 2011
From: sefaj at generalstudio.ch (Lorik Sefaj)
Date: Thu, 10 Nov 2011 17:00:48 +0100
Subject: c1xx with filter re-work
In-Reply-To: <5ac2cc31-0b35-46da-a8e7-4afdc1d5c517@email.android.com>
References: <CACsma44WYBUiY3OEHZsv5NsC5cx00v6kUobCjvXKB63hS=P4aQ@mail.gmail.com>
	<CAHL+j092E07DhwSHWXMHqTTsK_7BVj0xs7+nmu++CKKp4+yxVg@mail.gmail.com>
	<CACsma45GO10jGDPNLH=8Z6N9einBcGQJMD=y-3M30jqi8UqhAA@mail.gmail.com>
	<5ac2cc31-0b35-46da-a8e7-4afdc1d5c517@email.android.com>
Message-ID: <CACsma45+c9f=gieiSFRej8qOjrapNPiS5tpOOZ+BBYxKZEuNpg@mail.gmail.com>

nice. yes i belive you, what's the final price?

thanks
J

On Thu, Nov 10, 2011 at 4:51 PM, Harald Welte <laforge at gnumonks.org> wrote:

> ** we could provide one as early as next week. the price is high as there
> is a lot of time spent in re-soldering.
> --
> Sent from a mobile device, excuse my short response
>
>
> Lorik Sefaj <sefaj at generalstudio.ch> wrote:
>>
>> hehe "out of stock"
>>
>> but thanks anyways
>> J
>>
>> On Thu, Nov 10, 2011 at 3:18 PM, Sylvain Munaut <246tnt at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> > Considering my soldering skills and the fact that I just ruined a c123
>>> > trying to replace the filters (which was working perfectly with patched
>>> > burst_ind and got me a lot of downlink traffic to work with).
>>> >
>>> > Anyways without wasting your time my question is: does anybody have a
>>> c1xx
>>> > with filter re-work for sale?
>>>
>>> See http://shop.sysmocom.de/
>>>
>>> Cheers,
>>>
>>>    Sylvain
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111110/e0768f36/attachment.htm>

From laforge at gnumonks.org  Thu Nov 10 16:43:25 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 10 Nov 2011 17:43:25 +0100
Subject: c1xx with filter re-work
In-Reply-To: <CACsma45+c9f=gieiSFRej8qOjrapNPiS5tpOOZ+BBYxKZEuNpg@mail.gmail.com>
References: <CACsma44WYBUiY3OEHZsv5NsC5cx00v6kUobCjvXKB63hS=P4aQ@mail.gmail.com>
	<CAHL+j092E07DhwSHWXMHqTTsK_7BVj0xs7+nmu++CKKp4+yxVg@mail.gmail.com>
	<CACsma45GO10jGDPNLH=8Z6N9einBcGQJMD=y-3M30jqi8UqhAA@mail.gmail.com>
	<5ac2cc31-0b35-46da-a8e7-4afdc1d5c517@email.android.com>
	<CACsma45+c9f=gieiSFRej8qOjrapNPiS5tpOOZ+BBYxKZEuNpg@mail.gmail.com>
Message-ID: <20111110164325.GH28637@prithivi.gnumonks.org>

Hi Lorik,

On Thu, Nov 10, 2011 at 05:00:48PM +0100, Lorik Sefaj wrote:

> nice. yes i belive you, what's the final price?

like the shop says: EUR 142.80 including German VAT, for Export (like
switzerland) it would be EUR 120 + shipping.

let's take further discussion about ordering/pricing off this list, it
should stay technical.

-- 
- Harald Welte <laforge at gnumonks.org>           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  Fri Nov 11 10:49:17 2011
From: dario.lombardo at libero.it (Dario Lombardo)
Date: Fri, 11 Nov 2011 11:49:17 +0100
Subject: burst_ind not working
Message-ID: <CAOYJJfvTc5=MM=pQ_7StJm6dCxghrdsYmH+Y-K0G0H+ChppZew@mail.gmail.com>

Hi guys
I'm not able to use cell_log under the burst_ind branch.
I checkout the master, compile and run osmocon/cell_log. Everything works
(I can see the cells).
I checkout the branch, recompile, and run the same commands as before, but
I get from layer1:

[...]
PM MEAS: ARFCN=71, 0    dBm at baseband, -138 dBm at RF
DSP Error Status: 8
PM MEAS: ARFCN=72, 0    dBm at baseband, -138 dBm at RF
DSP Error Status: 8
PM MEAS: ARFCN=73, 0    dBm at baseband, -138 dBm at RF
[...]

for every arfcn. Cell_log doesn't log anything:

[...]
<000e> cell_log.c:359 Measurement done
<000e> cell_log.c:368 Measure from 0 to 124
<000e> cell_log.c:368 Measure from 512 to 885
<000e> cell_log.c:368 Measure from 955 to 1023
[...]

I don't think it's a hardware problem, since it works with master. Am I
missing something in the branch?
Is anyone experiencing the same problem?
Bye.
Dario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111111/bb24e030/attachment.htm>

From 246tnt at gmail.com  Fri Nov 11 11:04:06 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 11 Nov 2011 12:04:06 +0100
Subject: burst_ind not working
In-Reply-To: <CAOYJJfvTc5=MM=pQ_7StJm6dCxghrdsYmH+Y-K0G0H+ChppZew@mail.gmail.com>
References: <CAOYJJfvTc5=MM=pQ_7StJm6dCxghrdsYmH+Y-K0G0H+ChppZew@mail.gmail.com>
Message-ID: <CAHL+j09AQO3h_9H+vG90nXJL-mp5=7WNG65ijvOxAA+j4FWgyA@mail.gmail.com>

Hi,

> I'm not able to use cell_log under the burst_ind branch.

Yes, it's broken right now.

Either revert the last commit, or cherry-pick
4789b4a6627b452041b57f81ea91878de666bcc2 (which is in master but not
burst_ind yet)


Cheers,

    Sylvain



From dario.lombardo at libero.it  Mon Nov 14 10:06:09 2011
From: dario.lombardo at libero.it (Dario Lombardo)
Date: Mon, 14 Nov 2011 11:06:09 +0100
Subject: burst_ind not working
In-Reply-To: <CAHL+j09AQO3h_9H+vG90nXJL-mp5=7WNG65ijvOxAA+j4FWgyA@mail.gmail.com>
References: <CAOYJJfvTc5=MM=pQ_7StJm6dCxghrdsYmH+Y-K0G0H+ChppZew@mail.gmail.com>
	<CAHL+j09AQO3h_9H+vG90nXJL-mp5=7WNG65ijvOxAA+j4FWgyA@mail.gmail.com>
Message-ID: <CAOYJJfsvd0Vf-ZHBU1m0GVm3C94Q+rrWm6Gw5HkMBbhNJB=d7g@mail.gmail.com>

I have pulled the latest version and everything works now. If I run
ccch_scan (gprs decoding patch applied) I have the bursts.
But when I run the gprs decoder, I got

Type not handled! 40

If I try one the sample .dat files provided by srlabs.de, the decode is ok
and I see the datagrams on wireshark.

This message shows an unsupported message type. Can be due to the noise on
the phone? I have observed the same behaviour with an original phone and a
modified (filters changed) one, but this should not matter.

Can someone help me?

On Fri, Nov 11, 2011 at 12:04 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

> Hi,
>
> > I'm not able to use cell_log under the burst_ind branch.
>
> Yes, it's broken right now.
>
> Either revert the last commit, or cherry-pick
> 4789b4a6627b452041b57f81ea91878de666bcc2 (which is in master but not
> burst_ind yet)
>
>
> Cheers,
>
>    Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111114/3815b32b/attachment.htm>

From ikarus4ever at web.de  Fri Nov 11 11:21:45 2011
From: ikarus4ever at web.de (ikarus4ever at web.de)
Date: Fri, 11 Nov 2011 12:21:45 +0100
Subject: burst_ind not working
In-Reply-To: <CAOYJJfvTc5=MM=pQ_7StJm6dCxghrdsYmH+Y-K0G0H+ChppZew@mail.gmail.com>
References: <CAOYJJfvTc5=MM=pQ_7StJm6dCxghrdsYmH+Y-K0G0H+ChppZew@mail.gmail.com>
Message-ID: <4EBD0549.4050701@web.de>

Hi,

I got the same problem with cell_log. Sometimes even using the master!?

Also, I couldn't compile the master or burst_ind with GPS supprot. No
makefile has the "-lgps" flag set. A workaround for me was to add
a "-lgps" to "src/host/layer23/src/misc/Makefile.am" in line
"cell_log_LDADD = $(LDADD) -lm" (same thing for mobile)

Did I miss something on the GPS support?
It is the first time I got this issues with GPS. All the times before
it worked fine.
Ok, I had to delete the following statements in gps.c:
 68     /* gps is offline */
 69     if (gdata->online)
 70         goto gps_not_ready;
 71
 72     /* gps has no data */
 73     if (gps_waiting(gdata))
 74         goto gps_not_ready;
For some reason the libgps thinks my GPS is not ready, even if it
worked with "xgps"

Greetings
ikarus



Am 11.11.2011 11:49, schrieb Dario Lombardo:
> Hi guys I'm not able to use cell_log under the burst_ind branch. I
> checkout the master, compile and run osmocon/cell_log. Everything 
> works (I can see the cells). I checkout the branch, recompile, and
> run the same commands as before, but I get from layer1:
> 
> [...] PM MEAS: ARFCN=71, 0    dBm at baseband, -138 dBm at RF DSP
> Error Status: 8 PM MEAS: ARFCN=72, 0    dBm at baseband, -138 dBm
> at RF DSP Error Status: 8 PM MEAS: ARFCN=73, 0    dBm at baseband,
> -138 dBm at RF [...]
> 
> for every arfcn. Cell_log doesn't log anything:
> 
> [...] <000e> cell_log.c:359 Measurement done <000e> cell_log.c:368
> Measure from 0 to 124 <000e> cell_log.c:368 Measure from 512 to
> 885 <000e> cell_log.c:368 Measure from 955 to 1023 [...]
> 
> I don't think it's a hardware problem, since it works with master.
> Am I missing something in the branch? Is anyone experiencing the
> same problem? Bye. Dario.




From stefan.mandl1 at googlemail.com  Tue Nov 15 10:13:43 2011
From: stefan.mandl1 at googlemail.com (Stefan Mandl)
Date: Tue, 15 Nov 2011 11:13:43 +0100
Subject: Compile with DEBUG fail / i2c.c
Message-ID: <CAMnUd+eOp-m5MwxyvKC9Jh63q4Op-J-xjhuqXkNWVgKy2qg7jQ@mail.gmail.com>

Hello all,

if you compile with #ifdef DEBUG,

2 litte typo errors came up...

Regrads from stefan


my patch...


--- a/src/target/firmware/calypso/i2c.c
+++ b/src/target/firmware/calypso/i2c.c
@@ -67,7 +67,7 @@ int i2c_write(uint8_t chip, uint32_t addr, int alen,
const uint8_t *buffer, int
        if (len > 16)
                return -1;

-       printd("i2c_write(chip=0x%02u, addr=0x%02u): ", chip, addr)
+       printd("i2c_write(chip=0x%02u, addr=0x%02u): ", chip, addr);

        writeb(chip & 0x3f, I2C_REG(DEVICE_REG));
        writeb(addr & 0xff, I2C_REG(ADDRESS_REG));
@@ -91,7 +91,7 @@ int i2c_write(uint8_t chip, uint32_t addr, int alen,
const uint8_t *buffer, int
        /* wait until transfer completes */
        while (1) {
                uint8_t reg = readb(I2C_REG(STATUS_ACTIVITY_REG));
-               printd("I2C Status: 0x%02x\n", rerg & 0xf);
+               printd("I2C Status: 0x%02x\n", reg & 0xf);
                if (!(reg & I2C_STATUS_IDLE)) // 0: idle 1: not idle
                        break;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111115/7da217e5/attachment.htm>

From steve at steve-m.de  Tue Nov 15 16:44:46 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Tue, 15 Nov 2011 17:44:46 +0100
Subject: Compile with DEBUG fail / i2c.c
In-Reply-To: <CAMnUd+eOp-m5MwxyvKC9Jh63q4Op-J-xjhuqXkNWVgKy2qg7jQ@mail.gmail.com>
References: <CAMnUd+eOp-m5MwxyvKC9Jh63q4Op-J-xjhuqXkNWVgKy2qg7jQ@mail.gmail.com>
Message-ID: <4EC296FE.8020605@steve-m.de>

Hi,

On 15.11.2011 11:13, Stefan Mandl wrote:
> 2 litte typo errors came up...

> my patch...

Thanks for your patch, I just committed it.

Regards,
Steve



From msokolov at ivan.Harhan.ORG  Fri Nov 18 19:21:48 2011
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Fri, 18 Nov 2011 19:21:48 GMT
Subject: Diff between TWL3014 and TWL3025
Message-ID: <1111181921.AA29394@ivan.Harhan.ORG>

Hello GSM BB hackers,

I wonder, would anyone here happen to know what are the main diffs
between the TWL3014 and TWL3025 ABB chips?

TWL3025 is the chip that appears to be used in most of the phones
currently supported by OsmocomBB, but the presumably older TWL3014 is
the only one for which we have docs as part of the Calypso and
Leonardo documentation set at:

ftp://ifctfvax.Harhan.ORG/pub/GSM/Calypso

(The above FTP server is mine, but the content originates from the
 52rd.com Chinese forum linked to from some of the OsmocomBB wiki
 pages.)

Hence me wondering if anyone here knows what the actual differences
are...

I also recall seeing somewhere (don't remember where) that Iota
strictly means TWL3014, and that its successor (TWL3016?) is
supposedly called Syren rather than Iota and supports EDGE modulation.
If that is true, where does the TWL3025 fit into that picture then?
Is it a Iota variant or a Syren variant?  It ought to be newer than
TWL3016, right?  Does that mean it ought to support EDGE?  If so, what
stands in the way of EDGE support in phones like GTA02 that use the
TWL3025 ABB?  Lack of Calypso DSP support?  Or an RF front-end that
isn't compatible with EDGE modulation?

Or is TWL3025 a step backward from TWL3016, without EDGE support?  If
so, would anyone happen to know what its raison-d'etre is?  What does
it offer over the TWL3014?

Just wondering...

MS



From steve at steve-m.de  Fri Nov 18 19:47:31 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 18 Nov 2011 20:47:31 +0100
Subject: Diff between TWL3014 and TWL3025
In-Reply-To: <1111181921.AA29394@ivan.Harhan.ORG>
References: <1111181921.AA29394@ivan.Harhan.ORG>
Message-ID: <4EC6B653.8050403@steve-m.de>

Hi,

On 18.11.2011 20:21, Michael Sokolov wrote:

> Hence me wondering if anyone here knows what the actual differences
> are...

Well, some time ago I diffed the TWL3014 and TWL3025 datasheets, and
there is no technical difference at all (only 3014 replaced with 3025,
and some minor formatting changes).

Given that both chips work fine with osmocom (with the same revision of
DSP rom code on the Calypso side of things), I suspect that TI renamed
the chip because of some changes in the manufacturing process.

Regards,
Steve



From 246tnt at gmail.com  Fri Nov 18 19:47:40 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 18 Nov 2011 20:47:40 +0100
Subject: Diff between TWL3014 and TWL3025
In-Reply-To: <1111181921.AA29394@ivan.Harhan.ORG>
References: <1111181921.AA29394@ivan.Harhan.ORG>
Message-ID: <CAHL+j0-0CuhytrCNs5Ctzd-wAgGQX029gv-TbA6=hm4Z-Lg5gQ@mail.gmail.com>

On Fri, Nov 18, 2011 at 8:21 PM, Michael Sokolov
<msokolov at ivan.harhan.org> wrote:
> Hello GSM BB hackers,
>
> I wonder, would anyone here happen to know what are the main diffs
> between the TWL3014 and TWL3025 ABB chips?

Not much ... For our purposes they're identical.

> Hence me wondering if anyone here knows what the actual differences
> are...
>
> I also recall seeing somewhere (don't remember where) that Iota
> strictly means TWL3014, and that its successor (TWL3016?) is
> supposedly called Syren rather than Iota and supports EDGE modulation.

No it doesn't.

> If that is true, where does the TWL3025 fit into that picture then?
> Is it a Iota variant or a Syren variant?

I think they're all called "Iota" that's a generic designation for the ABB.

> ?It ought to be newer than TWL3016, right?

It is.

> ?Does that mean it ought to support EDGE?

No it doesn't ... because the 3016 doesn't. Nor does the 3029 either.

> If so, what
> stands in the way of EDGE support in phones like GTA02 that use the
> TWL3025 ABB? ?Lack of Calypso DSP support? ?Or an RF front-end that
> isn't compatible with EDGE modulation?

Missing DSP support and missing ABB support.


Cheers,

    Sylvain



From msokolov at ivan.Harhan.ORG  Fri Nov 18 20:51:01 2011
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Fri, 18 Nov 2011 20:51:01 GMT
Subject: Diff between TWL3014 and TWL3025
Message-ID: <1111182051.AA29577@ivan.Harhan.ORG>

Steve Markgraf <steve at steve-m.de> wrote:

> Well, some time ago I diffed the TWL3014 and TWL3025 datasheets,

Where did you find the TWL3025 datasheet?  Wading through 52rd.com, or
is there some other source I'm unaware of?

> there is no technical difference at all (only 3014 replaced with 3025,
> and some minor formatting changes).
> [...]
> I suspect that TI renamed
> the chip because of some changes in the manufacturing process.

Hmm, interesting.

> Given that both chips work fine with osmocom (with the same revision of
> DSP rom code on the Calypso side of things),

What OsmocomBB-supported phones use TWL3014?

Sylvain Munaut <246tnt at gmail.com> wrote:

> > supposedly called Syren rather than Iota and supports EDGE modulation.
> No it doesn't.
> [...]
> > Is it a Iota variant or a Syren variant?
> I think they're all called "Iota" that's a generic designation for the ABB.

I believe that the codenames refer to specific generations for each
function, rather than to functions like DBB/ABB/RF.  For example, it
seems that Calypso succeeded Hercules in the DBB role, and Rita
succeeded Clara in the RF role.

I remember seeing somewhere that Iota's successor was/is Syren,
whereas its predecessor in the ABB role was Nausica.  But if TWL3016
and TWL3025 are both Iotas, which chip is then Syren?  Does anyone
know?

MS



From 246tnt at gmail.com  Fri Nov 18 21:13:39 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 18 Nov 2011 22:13:39 +0100
Subject: Diff between TWL3014 and TWL3025
In-Reply-To: <1111182051.AA29577@ivan.Harhan.ORG>
References: <1111182051.AA29577@ivan.Harhan.ORG>
Message-ID: <CAHL+j09_MXZXv8mSiu2zyBF7cXnWspcDPgjksP+XvOYv2k9Wxg@mail.gmail.com>

> I remember seeing somewhere that Iota's successor was/is Syren,
> whereas its predecessor in the ABB role was Nausica. ?But if TWL3016
> and TWL3025 are both Iotas, which chip is then Syren? ?Does anyone
> know?

I always tought that Iota was a generic designation for then ABB in
the TI leonardo platform.
And then you also had specific codenames for the individual chips:
Syren is the TWL3016.
Triton is TWL3029.

But from re-reading various docs, it indeed might be a wrong
impression and Iota designation seems specific to TWL3014.

But seriously ... who cares ... If you need to refer to a specific
chip model, use the part number and not some obscure name.

Cheers,

    Sylvain



From steve at steve-m.de  Fri Nov 18 21:21:00 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 18 Nov 2011 22:21:00 +0100
Subject: Diff between TWL3014 and TWL3025
In-Reply-To: <1111182051.AA29577@ivan.Harhan.ORG>
References: <1111182051.AA29577@ivan.Harhan.ORG>
Message-ID: <4EC6CC3C.1020502@steve-m.de>

On 18.11.2011 21:51, Michael Sokolov wrote:

> Where did you find the TWL3025 datasheet?  Wading through 52rd.com, or
> is there some other source I'm unaware of?

Search Google for "TWL3025 SWRS021", last hit.

> What OsmocomBB-supported phones use TWL3014?

Motorola C155, V171, Pirelli DP-L10.


> I remember seeing somewhere that Iota's successor was/is Syren,
> whereas its predecessor in the ABB role was Nausica.  But if TWL3016
> and TWL3025 are both Iotas, which chip is then Syren?  Does anyone
> know?

Both TWL3014 and TWL3025 are Iota, TWL3016 is Syren.

Regards,
Steve



From msokolov at ivan.Harhan.ORG  Fri Nov 18 22:42:01 2011
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Fri, 18 Nov 2011 22:42:01 GMT
Subject: Diff between TWL3014 and TWL3025
Message-ID: <1111182242.AA29775@ivan.Harhan.ORG>

Steve Markgraf <steve at steve-m.de> wrote:

> Search Google for "TWL3025 SWRS021", last hit.

Thanks, got it.  (In my case it was the middle of the 3 results rather
than the last.)

I wonder about all these Chinese websites...  It looks like they have
a healthier attitude about sharing this kind of stuff than the
Westerners do.

So far we've known about 52rd.com hosting "contraband" phone handset
chip documents, and now we know there's also baisi.net...  But I find
it strange that only PDF datasheets and PPT presentations have been
found so far, and not, for example, any of the source/object-mix
packages that must have been given for the firmware side of things
by TI et al to the same folks (phone makers?) to whom they've given
the chip docs.  NDA etc issues ought to be the same...  Or maybe I
just haven't been looking hard enough...  Would anyone here perchance
happen to have a link to some place on one of those Chinese sites that
has the original FW source (or semi-source, as in bits of source mixed
with binary object blobs) for the Leonardo reference board or for some
other Calypso-based HW version that's more readily available (as in HW
availability) than the famous TSM30 version?

(I realize that it would never be acceptable to use any such code in a
 Western FOSS project like OsmocomBB, but I would still *love* to take
 a peek at the original code for some phone whose HW is better
 understood and/or more readily available than the TSM30.)

> Both TWL3014 and TWL3025 are Iota, TWL3016 is Syren.

Hmm.  I agree that TWL3025 must be some equivalent Iota variant, and I
think you are right about TWL3016 being Syren: the Rita_intro.pdf
document in my collection (see my FTP site) says "It is compatible
with Iota (TWL3014) and Syren (TWL3016) ABB chips".  However, the
Iota_intro.pdf document (same FTP site) shows the Nausica->Iota->Syren
evolutionary line and lists Syren as EDGE-capable.  But Sylvain says
TWL3016 doesn't do EDGE either.  Hmm.  Are you sure?

MS



From 246tnt at gmail.com  Sat Nov 19 07:30:41 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 19 Nov 2011 08:30:41 +0100
Subject: Diff between TWL3014 and TWL3025
In-Reply-To: <1111182242.AA29775@ivan.Harhan.ORG>
References: <1111182242.AA29775@ivan.Harhan.ORG>
Message-ID: <CAHL+j0-yz6dfcK7G4U4pbC-gNmpQkTBMHmJqD72yZR1O1tGjtg@mail.gmail.com>

> I wonder about all these Chinese websites... ?It looks like they have
> a healthier attitude about sharing this kind of stuff than the
> Westerners do.

They just don't care about IP and lawsuits ... :)

>?But Sylvain says
> TWL3016 doesn't do EDGE either. ?Hmm. ?Are you sure?

Google for  TWL3016 SWCS010  and check for yourself

Cheers,

    Sylvain



From msokolov at ivan.Harhan.ORG  Sat Nov 19 08:08:09 2011
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Sat, 19 Nov 2011 08:08:09 GMT
Subject: Diff between TWL3014 and TWL3025
Message-ID: <1111190808.AA00332@ivan.Harhan.ORG>

Sylvain Munaut <246tnt at gmail.com> wrote:

> Google for  TWL3016 SWCS010  and check for yourself

Thanks once again!

OK, so TWL3016 *is* Syren indeed, and it does have additional features
over Iota.  But EDGE modulation support isn't one of them.  If my
reading of the doc is correct, the additional features of Syren over
Iota are I2S audio, high voltage charger input and the USB regulator
support.  Does this agree with your reading?

MS



From acassis at gmail.com  Sat Nov 19 20:19:51 2011
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Sat, 19 Nov 2011 18:19:51 -0200
Subject: OsmocomBB on Motorola W220
Message-ID: <CAG4Y6eTn=8S-hvvZuPPCai4gr3qYqURGaBPhMkh50qjS8YnZJw@mail.gmail.com>

Hi all,

I want to know if someone here already tried osmocombb on Motorola W220?

This cell phone is powered by D751749ZPH, but at least my model (W220
E2) doesn't communicate with "osmocon". The problem is not serial
cable because it work correctly with C115.

After some search I discovered the uart is disabled by software, some
firmware version let users to enable it after entering on engineering
mode (*#**372#), unfortunately my firmware doesn't have this option at
eng. mode.

You can see a picture of my W220 board here:
http://acassis.files.wordpress.com/2011/11/sam_1634.jpg

If someone has some idea for an alternative option (JTAG?) please tell me.

BR,

Alan



From steve at steve-m.de  Sat Nov 19 21:04:35 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Sat, 19 Nov 2011 22:04:35 +0100
Subject: OsmocomBB on Motorola W220
In-Reply-To: <CAG4Y6eTn=8S-hvvZuPPCai4gr3qYqURGaBPhMkh50qjS8YnZJw@mail.gmail.com>
References: <CAG4Y6eTn=8S-hvvZuPPCai4gr3qYqURGaBPhMkh50qjS8YnZJw@mail.gmail.com>
Message-ID: <4EC819E3.4000500@steve-m.de>

Hi,

On 19.11.2011 21:19, Alan Carvalho de Assis wrote:

> After some search I discovered the uart is disabled by software, some
> firmware version let users to enable it after entering on engineering
> mode (*#**372#), unfortunately my firmware doesn't have this option at
> eng. mode.

The phone doesn't use the Compal ramloader (it is manufactured by
Chi-Mei), but it uses the Calypso romloader.

Loading osmocom will work fine with "-m romload" and a highram image,
however, the Si4210 GSM transceiver it uses is currently unsupported in
osmocom.
Feel free to write a driver for it though, the register-level datasheet
is floating around somewhere.

Regards,
Steve



From acassis at gmail.com  Sat Nov 19 23:28:48 2011
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Sat, 19 Nov 2011 21:28:48 -0200
Subject: OsmocomBB on Motorola W220
In-Reply-To: <4EC819E3.4000500@steve-m.de>
References: <CAG4Y6eTn=8S-hvvZuPPCai4gr3qYqURGaBPhMkh50qjS8YnZJw@mail.gmail.com>
	<4EC819E3.4000500@steve-m.de>
Message-ID: <CAG4Y6eQk_L=jYm3ijNa5JEfrznb0EhRTZtqitTn0-JjcyE18Pg@mail.gmail.com>

Hi Steve,

On 11/19/11, Steve Markgraf <steve at steve-m.de> wrote:
> Hi,
>
> On 19.11.2011 21:19, Alan Carvalho de Assis wrote:
>
>> After some search I discovered the uart is disabled by software, some
>> firmware version let users to enable it after entering on engineering
>> mode (*#**372#), unfortunately my firmware doesn't have this option at
>> eng. mode.
>
> The phone doesn't use the Compal ramloader (it is manufactured by
> Chi-Mei), but it uses the Calypso romloader.
>
> Loading osmocom will work fine with "-m romload" and a highram image,

Thank you very much.

It worked fine!

> however, the Si4210 GSM transceiver it uses is currently unsupported in
> osmocom.
> Feel free to write a driver for it though, the register-level datasheet
> is floating around somewhere.
>

I'm looking for this datasheet.

BR,

Alan



From alexander.huemer at xx.vu  Sun Nov 20 20:43:25 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Sun, 20 Nov 2011 21:43:25 +0100
Subject: [PATCH] rf: dereference pointer
Message-ID: <1321821805-5787-1-git-send-email-alexander.huemer@xx.vu>

---
 src/target/firmware/rf/mt6139.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/target/firmware/rf/mt6139.c b/src/target/firmware/rf/mt6139.c
index a9a6d32..d48e652 100644
--- a/src/target/firmware/rf/mt6139.c
+++ b/src/target/firmware/rf/mt6139.c
@@ -39,13 +39,13 @@ static void mt6139_compute_pll(uint32_t f_vco_100khz,
 	/* To compute Nint, we assume Nfrac is zero */
 	*nint = (fvco_100khz / (10 * 2 * 26)) - (0 / 130);
 
-	if (nint > 127)
+	if (*nint > 127)
 		printf("VCO Frequency %u kHz is out of spec\n", f_vco_100khz);
 
 	/* Compute Nfract using the pre-computed Nint */
 	/* Nfrac = ( (Fvco/2*26) - Nint) * 130 */
 	/* Nfrac = ( (Fvco*130)/(2*26) - (Nint * 130) */
-	*nfrac = (f_vco_100khz*130)/(52*10) - (nint * 130);
+	*nfrac = (f_vco_100khz*130)/(52*10) - (*nint * 130);
 }
 
 /* Set ARFCN.  Takes 2 reg_write, i.e. 8 TPU instructions */
-- 
1.7.8.rc1




From holger at freyther.de  Sun Nov 20 21:10:12 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 20 Nov 2011 22:10:12 +0100
Subject: [PATCH] rf: dereference pointer
In-Reply-To: <1321821805-5787-1-git-send-email-alexander.huemer@xx.vu>
References: <1321821805-5787-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <4EC96CB4.8010302@freyther.de>

On 11/20/2011 09:43 PM, Alexander Huemer wrote:

how did you find this? manual review? compiler warning? clang?



From alexander.huemer at xx.vu  Mon Nov 21 08:44:06 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Mon, 21 Nov 2011 09:44:06 +0100
Subject: [PATCH] rf: dereference pointer
In-Reply-To: <4EC96CB4.8010302@freyther.de>
References: <1321821805-5787-1-git-send-email-alexander.huemer@xx.vu>
	<4EC96CB4.8010302@freyther.de>
Message-ID: <20111121084405.GA17479@de.xx.vu>

On Sun, Nov 20, 2011 at 10:10:12PM +0100, Holger Hans Peter Freyther wrote:
> On 11/20/2011 09:43 PM, Alexander Huemer wrote:
> 
> how did you find this? manual review? compiler warning? clang?
> 
manual review, just a coincidence.



From steve at steve-m.de  Sun Nov 20 23:52:35 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 21 Nov 2011 00:52:35 +0100
Subject: [PATCH] rf: dereference pointer
In-Reply-To: <1321821805-5787-1-git-send-email-alexander.huemer@xx.vu>
References: <1321821805-5787-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <4EC992C3.2050100@steve-m.de>

Committed it to master.

Regards,
Steve



From sefaj at generalstudio.ch  Wed Nov 23 14:16:55 2011
From: sefaj at generalstudio.ch (Lorik Sefaj)
Date: Wed, 23 Nov 2011 15:16:55 +0100
Subject: uplink sniffing
Message-ID: <CACsma44UTcs4-KgJB2fhmfrud1k3ARQ1asvF0HgYbpkL5cLzkA@mail.gmail.com>

Hi all,
Just received my C123 (from http://shop.sysmocom.de/) with filter rework
and it works great.

I have one problem with the "burst*.dat" files when i do uplink sniffing,
basically there are no files produced and when they are produced most of
the time they are empty?
This doesn't happen when i do downlink sniffing. Is this a stupid question
or am I missing something...

cheers,
L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111123/198a7d15/attachment.htm>

From holger at freyther.de  Thu Nov 24 10:52:44 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 24 Nov 2011 11:52:44 +0100
Subject: uplink sniffing
In-Reply-To: <CACsma44UTcs4-KgJB2fhmfrud1k3ARQ1asvF0HgYbpkL5cLzkA@mail.gmail.com>
References: <CACsma44UTcs4-KgJB2fhmfrud1k3ARQ1asvF0HgYbpkL5cLzkA@mail.gmail.com>
Message-ID: <4ECE21FC.50009@freyther.de>

On 11/23/2011 03:16 PM, Lorik Sefaj wrote:
> Hi all,

> This doesn't happen when i do downlink sniffing. Is this a stupid question or
> am I missing something...

Hi,

I assume this is with the GPRS code? I had hoped someone who has actually done
this would respond (I never tried the GPRS sniffing code).

I can only offer generic debugging advice (that you might have already
considered):

	- I assume you followed the advice to go from #if 1 to #if 0?

	- Check if the uplink sniffing cmd set is scheduled. The cmd_set for
	  sniffing (sniff_tch_sched_set) is used in the layer1/mframe_sched.c
	  and the TCH_F_EVEN/ODD task is triggered by
	  l23_api.c:l1ctl_rx_dm_est_req (from what I see right now).

	- Is l1s_sniff_resp called? The wiki mentions red burst ind messages
	  popping up somewhere.


holger



From 246tnt at gmail.com  Thu Nov 24 11:03:00 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 24 Nov 2011 12:03:00 +0100
Subject: uplink sniffing
In-Reply-To: <4ECE21FC.50009@freyther.de>
References: <CACsma44UTcs4-KgJB2fhmfrud1k3ARQ1asvF0HgYbpkL5cLzkA@mail.gmail.com>
	<4ECE21FC.50009@freyther.de>
Message-ID: <CAHL+j09+gPiVGSFFbYbTsNxpMO=y_6pXheSwpFM+m94nNe5K-g@mail.gmail.com>

Hi,

> I assume this is with the GPRS code? I had hoped someone who has actually done
> this would respond (I never tried the GPRS sniffing code).

Ah yes, I forgot about this ...

I don't know what you run, but it's also completely possible that you
just don't see uplinks ... just because the filters are removed
doesn't mean you'll see as much UL traffic than DL traffic, the range
is still much more limited.

Cheers,

    Sylvain



From sefaj at generalstudio.ch  Thu Nov 24 12:34:30 2011
From: sefaj at generalstudio.ch (Lorik Sefaj)
Date: Thu, 24 Nov 2011 13:34:30 +0100
Subject: uplink sniffing
In-Reply-To: <CAHL+j09+gPiVGSFFbYbTsNxpMO=y_6pXheSwpFM+m94nNe5K-g@mail.gmail.com>
References: <CACsma44UTcs4-KgJB2fhmfrud1k3ARQ1asvF0HgYbpkL5cLzkA@mail.gmail.com>
	<4ECE21FC.50009@freyther.de>
	<CAHL+j09+gPiVGSFFbYbTsNxpMO=y_6pXheSwpFM+m94nNe5K-g@mail.gmail.com>
Message-ID: <CACsma44wW2wt8YuUAwP=7=G0H-ovg=nEKzwqRBV+QJoyFXZOjg@mail.gmail.com>

Thanks. Yes I thought about the UL range at first and I think your
reply pretty much affirms my conclusion too.
I'm using the GPRS code (from #if 1 to #if 0) I will check the debugging
advice from Holger.

cheers,
L.
On Thu, Nov 24, 2011 at 12:03 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

> Hi,
>
> > I assume this is with the GPRS code? I had hoped someone who has
> actually done
> > this would respond (I never tried the GPRS sniffing code).
>
> Ah yes, I forgot about this ...
>
> I don't know what you run, but it's also completely possible that you
> just don't see uplinks ... just because the filters are removed
> doesn't mean you'll see as much UL traffic than DL traffic, the range
> is still much more limited.
>
> Cheers,
>
>    Sylvain
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111124/f7adcd4a/attachment.htm>

From technosabby at gmail.com  Sat Nov 26 20:36:29 2011
From: technosabby at gmail.com (Marten Christophe)
Date: Sat, 26 Nov 2011 20:36:29 +0000
Subject: uplink sniffing
In-Reply-To: <CAHL+j09+gPiVGSFFbYbTsNxpMO=y_6pXheSwpFM+m94nNe5K-g@mail.gmail.com>
References: <CACsma44UTcs4-KgJB2fhmfrud1k3ARQ1asvF0HgYbpkL5cLzkA@mail.gmail.com>
	<4ECE21FC.50009@freyther.de>
	<CAHL+j09+gPiVGSFFbYbTsNxpMO=y_6pXheSwpFM+m94nNe5K-g@mail.gmail.com>
Message-ID: <CAFQoMP+pByMXy2794sxpf5ZTY9NL4nOsbFB-aSDTO=0mvpOVsQ@mail.gmail.com>

Hello List,

I I'm keen to know if TCH sniff features were added to OsmocomBB( as
Sylvain demonstrated during C27 chao conference)? does it capable to do the
voice channel sniffing as well? whether real time or in recorded.

Kind regards,
On Thu, Nov 24, 2011 at 11:03 AM, Sylvain Munaut <246tnt at gmail.com> wrote:

> Hi,
>
> > I assume this is with the GPRS code? I had hoped someone who has
> actually done
> > this would respond (I never tried the GPRS sniffing code).
>
> Ah yes, I forgot about this ...
>
> I don't know what you run, but it's also completely possible that you
> just don't see uplinks ... just because the filters are removed
> doesn't mean you'll see as much UL traffic than DL traffic, the range
> is still much more limited.
>
> Cheers,
>
>    Sylvain
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111126/f770de76/attachment.htm>

From holger at freyther.de  Sat Nov 26 20:42:42 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sat, 26 Nov 2011 21:42:42 +0100
Subject: uplink sniffing
In-Reply-To: <CAFQoMP+pByMXy2794sxpf5ZTY9NL4nOsbFB-aSDTO=0mvpOVsQ@mail.gmail.com>
References: <CACsma44UTcs4-KgJB2fhmfrud1k3ARQ1asvF0HgYbpkL5cLzkA@mail.gmail.com>	<4ECE21FC.50009@freyther.de>	<CAHL+j09+gPiVGSFFbYbTsNxpMO=y_6pXheSwpFM+m94nNe5K-g@mail.gmail.com>
	<CAFQoMP+pByMXy2794sxpf5ZTY9NL4nOsbFB-aSDTO=0mvpOVsQ@mail.gmail.com>
Message-ID: <4ED14F42.60900@freyther.de>

On 11/26/2011 09:36 PM, Marten Christophe wrote:
> 
> Hello List,
>  
> I I'm keen to know if TCH sniff features were added to OsmocomBB( as Sylvain
> demonstrated during C27 chao conference)? does it capable to do the voice
> channel sniffing as well? whether real time or in recorded.

Hi,

can you just let it go? Sylvain has clearly stated that the code he wrote to
make sniffing + decoding trivial will not be published. Why do you come back
with that? It is getting a bit freaky.

His dsp patch to get raw burst data has been always public[1]...

holger

[1]
http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target_dsp/calypso/dsp_sniff.S?h=sylvain/burst_ind




From alexander.huemer at xx.vu  Wed Nov 23 22:59:36 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:36 +0100
Subject: [PATCH 0/0] firmware janitor work to reduce compiler warnings
Message-ID: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>

This patch series reduces the number of warnings emitted during firmware
compilation. No functional changes.
The patches could NOT be TESTED, so please try them before merging.

Kind regards,
-Alexander Huemer




From alexander.huemer at xx.vu  Wed Nov 23 22:59:37 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:37 +0100
Subject: [PATCH 1/8] firmware: correct format strings
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-2-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warning
warning: format ??? expects type ???, but argument ? has type ???
---
 src/target/firmware/apps/loader/main.c |    4 ++--
 src/target/firmware/calypso/dsp.c      |    5 +++--
 src/target/firmware/calypso/keypad.c   |    3 ++-
 src/target/firmware/flash/cfi_flash.c  |   13 +++++++------
 src/target/firmware/layer1/prim_fbsb.c |    9 +++++----
 src/target/firmware/layer1/prim_freq.c |    3 ++-
 6 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c
index 2ff6f9c..18f0b36 100644
--- a/src/target/firmware/apps/loader/main.c
+++ b/src/target/firmware/apps/loader/main.c
@@ -162,13 +162,13 @@ int main(void)
 	if (flash_init(&the_flash, 0)) {
 		puts("Failed to initialize flash!\n");
 	} else {
-		printf("Found flash of %d bytes at 0x%x with %d regions\n",
+		printf("Found flash of %zu bytes at 0x%p with %zu regions\n",
 		       the_flash.f_size, the_flash.f_base,
 		       the_flash.f_nregions);
 
 		int i;
 		for (i = 0; i < the_flash.f_nregions; i++) {
-			printf("  Region %d of %d pages with %d bytes each.\n",
+			printf("  Region %d of %zu pages with %zu bytes each.\n",
 			       i,
 			       the_flash.f_regions[i].fr_bnum,
 			       the_flash.f_regions[i].fr_bsize);
diff --git a/src/target/firmware/calypso/dsp.c b/src/target/firmware/calypso/dsp.c
index 1daecb2..8bf9749 100644
--- a/src/target/firmware/calypso/dsp.c
+++ b/src/target/firmware/calypso/dsp.c
@@ -23,6 +23,7 @@
 
 #include <stdint.h>
 #include <stdio.h>
+#include <inttypes.h>
 
 #include <debug.h>
 #include <delay.h>
@@ -639,7 +640,7 @@ static void _dsp_dump_range(uint32_t addr, uint32_t size, int mode)
 			 * the sercomm buffer */
 			delay_ms(2);
 			if ((addr&15)==0)
-				printf("%05x : ", addr);
+				printf("%05"PRIx32" : ", addr);
 			printf("%04hx%c", *api++, ((addr&15)==15)?'\n':' ');
 			addr++;
 		}
@@ -685,7 +686,7 @@ void dsp_dump(void)
 
 	/* Dump each range */
 	for (i=0; dr[i].name; i++) {
-		printf("DSP dump: %s [%05x-%05x]\n", dr[i].name,
+		printf("DSP dump: %s [%05"PRIx32"-%05lx]\n", dr[i].name,
 			dr[i].addr, dr[i].addr+dr[i].size-1);
 		_dsp_dump_range(dr[i].addr, dr[i].size, dr[i].mode);
 	}
diff --git a/src/target/firmware/calypso/keypad.c b/src/target/firmware/calypso/keypad.c
index fd4e0ff..30fb3b9 100644
--- a/src/target/firmware/calypso/keypad.c
+++ b/src/target/firmware/calypso/keypad.c
@@ -22,6 +22,7 @@
 
 #include <stdint.h>
 #include <stdio.h>
+#include <inttypes.h>
 
 #include <defines.h>
 #include <debug.h>
@@ -98,7 +99,7 @@ void dispatch_buttons(uint32_t buttons)
 		else if BTN_TO_KEY(OK)
 		else
 		{
-			printf("\nunknown keycode: 0x%08x\n", diff);
+			printf("\nunknown keycode: 0x%08"PRIx32"\n", diff);
 			break;
 		}
 		emit_key(key, state);
diff --git a/src/target/firmware/flash/cfi_flash.c b/src/target/firmware/flash/cfi_flash.c
index 69369d5..4f31d78 100644
--- a/src/target/firmware/flash/cfi_flash.c
+++ b/src/target/firmware/flash/cfi_flash.c
@@ -24,6 +24,7 @@
 #include <stdio.h>
 #include <stdint.h>
 #include <errno.h>
+#include <inttypes.h>
 #include <memory.h>
 #include <defines.h>
 #include <flash/cfi_flash.h>
@@ -184,7 +185,7 @@ int flash_block_unlock(flash_t * flash, uint32_t block_offset)
 		return -EPERM;
 	}
 
-	printf("Unlocking block at 0x%08x, meaning %08x\n",
+	printf("Unlocking block at 0x%08"PRIx32", meaning %8p\n",
 		   block_offset, base_addr + block_offset);
 
 	flash_write_cmd(base_addr, CFI_CMD_PROTECT);
@@ -203,7 +204,7 @@ int flash_block_lock(flash_t * flash, uint32_t block_offset)
 		return -EINVAL;
 	}
 
-	printf("Locking block at 0x%08x\n", block_offset);
+	printf("Locking block at 0x%08"PRIx32"\n", block_offset);
 
 	flash_write_cmd(base_addr, CFI_CMD_PROTECT);
 	flash_write_cmd(base_addr + block_offset, CFI_PROT_LOCK);
@@ -221,7 +222,7 @@ int flash_block_lockdown(flash_t * flash, uint32_t block_offset)
 		return -EINVAL;
 	}
 
-	printf("Locking down block at 0x%08x\n", block_offset);
+	printf("Locking down block at 0x%08"PRIx32"\n", block_offset);
 
 	flash_write_cmd(base_addr, CFI_CMD_PROTECT);
 	flash_write_cmd(base_addr + block_offset, CFI_PROT_LOCKDOWN);
@@ -243,7 +244,7 @@ int flash_block_erase(flash_t * flash, uint32_t block_offset)
 		return -EPERM;
 	}
 
-	printf("Erasing block 0x%08x...", block_offset);
+	printf("Erasing block 0x%08"PRIx32"...", block_offset);
 
 	void *block_addr = ((uint8_t *) base_addr) + block_offset;
 
@@ -313,7 +314,7 @@ int flash_program(flash_t * flash, uint32_t dst, void *src, uint32_t nbytes)
 	}
 
 	/* say something */
-	printf("Programming %u bytes to 0x%08x from 0x%p...", nbytes, dst, src);
+	printf("Programming %"PRIu32" bytes to 0x%08"PRIx32" from 0x%p...", nbytes, dst, src);
 
 	/* clear status register */
 	flash_write_cmd(base_addr, CFI_CMD_CLEAR_STATUS);
@@ -373,7 +374,7 @@ int flash_program(flash_t * flash, uint32_t dst, void *src, uint32_t nbytes)
 	flash_write_cmd(base_addr, CFI_CMD_RESET);
 
  err:
-	printf(" at offset 0x%x\n", i);
+	printf(" at offset 0x%"PRIx32"\n", i);
 
 	return res;
 }
diff --git a/src/target/firmware/layer1/prim_fbsb.c b/src/target/firmware/layer1/prim_fbsb.c
index 7affd75..023902d 100644
--- a/src/target/firmware/layer1/prim_fbsb.c
+++ b/src/target/firmware/layer1/prim_fbsb.c
@@ -25,6 +25,7 @@
 #include <string.h>
 #include <stdlib.h>
 #include <errno.h>
+#include <inttypes.h>
 
 #include <defines.h>
 #include <debug.h>
@@ -93,7 +94,7 @@ static void dump_mon_state(struct mon_state *fb)
 		fb->snr, l1s_snr_int(fb->snr), l1s_snr_fract(fb->snr),
 		tpu_get_offset(), tpu_get_synchro());
 #else
-	printf("(%u:%u): TOA=%5u, Power=%4ddBm, Angle=%5dHz\n",
+	printf("(%"PRIu32":%u): TOA=%5u, Power=%4ddBm, Angle=%5dHz\n",
 		fb->fnr_report, fb->attempt, fb->toa,
 		agc_inp_dbm8_by_pm(fb->pm)/8, ANGLE_TO_FREQ(fb->angle));
 #endif
@@ -201,7 +202,7 @@ static int l1s_sbdet_resp(__unused uint8_t p1, uint8_t attempt,
 
 	sb = dsp_api.db_r->a_sch[3] | dsp_api.db_r->a_sch[4] << 16;
 	fbs.mon.bsic = l1s_decode_sb(&fbs.mon.time, sb);
-	printf("=> SB 0x%08x: BSIC=%u ", sb, fbs.mon.bsic);
+	printf("=> SB 0x%08"PRIx32": BSIC=%u ", sb, fbs.mon.bsic);
 	l1s_time_dump(&fbs.mon.time);
 
 	l1s.serving_cell.bsic = fbs.mon.bsic;
@@ -480,9 +481,9 @@ static int l1s_fbdet_resp(__unused uint8_t p1, uint8_t attempt,
 
 			int fn_offset = l1s.current_time.fn - last_fb->attempt + ntdma;
 			int delay = fn_offset + 11 - l1s.current_time.fn - 1;
-			printf("  fn_offset=%d (fn=%u + attempt=%u + ntdma = %d)\n",
+			printf("  fn_offset=%d (fn=%"PRIu32" + attempt=%u + ntdma = %d)\n",
 				fn_offset, l1s.current_time.fn, last_fb->attempt, ntdma);
-			printf("  delay=%d (fn_offset=%d + 11 - fn=%u - 1\n", delay,
+			printf("  delay=%d (fn_offset=%d + 11 - fn=%"PRIu32" - 1\n", delay,
 				fn_offset, l1s.current_time.fn);
 			printf("  scheduling next FB/SB detection task with delay %u\n", delay);
 			if (abs(last_fb->freq_diff) < fbs.req.freq_err_thresh2 &&
diff --git a/src/target/firmware/layer1/prim_freq.c b/src/target/firmware/layer1/prim_freq.c
index 88bc453..64e08b5 100644
--- a/src/target/firmware/layer1/prim_freq.c
+++ b/src/target/firmware/layer1/prim_freq.c
@@ -24,6 +24,7 @@
 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #include <defines.h>
 #include <debug.h>
@@ -102,7 +103,7 @@ void l1a_freq_req(uint32_t fn_sched)
 	fn_sched = l1s.current_time.fn + diff;
 	if (fn_sched >= GSM_MAX_FN)
 		fn_sched -= GSM_MAX_FN;
-	printf("Scheduling frequency change at fn=%u, currently fn=%u\n",
+	printf("Scheduling frequency change at fn=%"PRIu32", currently fn=%"PRIu32"\n",
 		fn_sched, l1s.current_time.fn);
 
 	local_firq_save(flags);
-- 
1.7.8.rc1




From alexander.huemer at xx.vu  Wed Nov 23 22:59:38 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:38 +0100
Subject: [PATCH 2/8] firmware: mark unused params, remove unused vars
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-3-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warning
warning: unused parameter ???
---
 src/target/firmware/apps/hello_world/main.c        |    3 ++-
 src/target/firmware/board/compal/rffe_dualband.c   |    6 ++++--
 .../firmware/board/compal_e86/rffe_dualband_e86.c  |    6 ++++--
 .../firmware/board/gta0x/rffe_gta0x_triband.c      |    6 ++++--
 .../board/pirelli_dpl10/rffe_dpl10_triband.c       |    6 ++++--
 src/target/firmware/calypso/i2c.c                  |    3 ++-
 src/target/firmware/calypso/sim.c                  |    3 ++-
 src/target/firmware/comm/msgb.c                    |    4 +++-
 src/target/firmware/comm/timer.c                   |    4 +++-
 src/target/firmware/display/ssd1783.c              |    4 +++-
 src/target/firmware/display/ssd1963.c              |    6 +++---
 src/target/firmware/display/td014.c                |    4 +++-
 src/target/firmware/flash/cfi_flash.c              |    3 +++
 src/target/firmware/layer1/afc.c                   |    3 ++-
 src/target/firmware/layer1/apc.c                   |    4 +++-
 src/target/firmware/layer1/l23_api.c               |    8 +++-----
 src/target/firmware/layer1/prim_fbsb.c             |    6 +-----
 src/target/firmware/layer1/prim_rach.c             |    1 -
 src/target/firmware/layer1/prim_tch.c              |    2 +-
 src/target/firmware/layer1/prim_tx_nb.c            |    1 -
 src/target/firmware/layer1/toa.c                   |    3 ++-
 src/target/firmware/layer1/tpu_window.c            |    2 +-
 src/target/firmware/rf/trf6151.c                   |    6 ++++++
 23 files changed, 59 insertions(+), 35 deletions(-)

diff --git a/src/target/firmware/apps/hello_world/main.c b/src/target/firmware/apps/hello_world/main.c
index 5e3ed85..56598b9 100644
--- a/src/target/firmware/apps/hello_world/main.c
+++ b/src/target/firmware/apps/hello_world/main.c
@@ -24,6 +24,7 @@
 #include <stdio.h>
 #include <string.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <delay.h>
@@ -59,7 +60,7 @@ static void console_rx_cb(uint8_t dlci, struct msgb *msg)
 	msgb_free(msg);
 }
 
-static void l1a_l23_rx_cb(uint8_t dlci, struct msgb *msg)
+static void l1a_l23_rx_cb(__unused uint8_t dlci, struct msgb *msg)
 {
 	int i;
 	puts("l1a_l23_rx_cb: ");
diff --git a/src/target/firmware/board/compal/rffe_dualband.c b/src/target/firmware/board/compal/rffe_dualband.c
index f4b7361..995c03b 100644
--- a/src/target/firmware/board/compal/rffe_dualband.c
+++ b/src/target/firmware/board/compal/rffe_dualband.c
@@ -1,6 +1,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <rffe.h>
@@ -23,7 +24,7 @@
 #define		RITA_STROBE	TSPEN(2)	/* Strobe for the Rita TSP */
 
 /* switch RF Frontend Mode */
-void rffe_mode(enum gsm_band band, int tx)
+void rffe_mode(__unused enum gsm_band band, __unused int tx)
 {
 	uint16_t tspact = tsp_act_state();
 
@@ -96,7 +97,8 @@ void rffe_compute_gain(int16_t exp_inp, int16_t target_bb)
 	trf6151_compute_gain(exp_inp, target_bb);
 }
 
-void rffe_rx_win_ctrl(int16_t exp_inp, int16_t target_bb)
+void rffe_rx_win_ctrl(__unused int16_t exp_inp, __unused int16_t target_bb)
 {
+#warning function not implemented yet
 	/* FIXME */
 }
diff --git a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c
index 25bb099..a71a6d4 100644
--- a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c
+++ b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c
@@ -1,6 +1,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <rffe.h>
@@ -26,7 +27,7 @@
 #define		RITA_STROBE	TSPEN(2)	/* Strobe for the Rita TSP */
 
 /* switch RF Frontend Mode */
-void rffe_mode(enum gsm_band band, int tx)
+void rffe_mode(__unused enum gsm_band band, __unused int tx)
 {
 	uint16_t tspact = tsp_act_state();
 
@@ -100,7 +101,8 @@ void rffe_compute_gain(int16_t exp_inp, int16_t target_bb)
 	trf6151_compute_gain(exp_inp, target_bb);
 }
 
-void rffe_rx_win_ctrl(int16_t exp_inp, int16_t target_bb)
+void rffe_rx_win_ctrl(__unused int16_t exp_inp, __unused int16_t target_bb)
 {
+#warning function not implemented yet
 	/* FIXME */
 }
diff --git a/src/target/firmware/board/gta0x/rffe_gta0x_triband.c b/src/target/firmware/board/gta0x/rffe_gta0x_triband.c
index f118d29..c138fde 100644
--- a/src/target/firmware/board/gta0x/rffe_gta0x_triband.c
+++ b/src/target/firmware/board/gta0x/rffe_gta0x_triband.c
@@ -1,6 +1,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <rffe.h>
@@ -27,7 +28,7 @@
 #define		RITA_STROBE	TSPEN(2)	/* Strobe for the Rita TSP */
 
 /* switch RF Frontend Mode */
-void rffe_mode(enum gsm_band band, int tx)
+void rffe_mode(enum gsm_band band, __unused int tx)
 {
 	uint16_t tspact = tsp_act_state();
 
@@ -125,7 +126,8 @@ void rffe_compute_gain(int16_t exp_inp, int16_t target_bb)
 	trf6151_compute_gain(exp_inp, target_bb);
 }
 
-void rffe_rx_win_ctrl(int16_t exp_inp, int16_t target_bb)
+void rffe_rx_win_ctrl(__unused int16_t exp_inp, __unused int16_t target_bb)
 {
+#warning function not implemented yet
 	/* FIXME */
 }
diff --git a/src/target/firmware/board/pirelli_dpl10/rffe_dpl10_triband.c b/src/target/firmware/board/pirelli_dpl10/rffe_dpl10_triband.c
index d4d1342..e17dd6b 100644
--- a/src/target/firmware/board/pirelli_dpl10/rffe_dpl10_triband.c
+++ b/src/target/firmware/board/pirelli_dpl10/rffe_dpl10_triband.c
@@ -1,6 +1,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <rffe.h>
@@ -28,7 +29,7 @@
 #define		RITA_STROBE	TSPEN(1)	/* Strobe for the Rita TSP */
 
 /* switch RF Frontend Mode */
-void rffe_mode(enum gsm_band band, int tx)
+void rffe_mode(enum gsm_band band, __unused int tx)
 {
 	uint16_t tspact = tsp_act_state();
 
@@ -130,7 +131,8 @@ void rffe_compute_gain(int16_t exp_inp, int16_t target_bb)
 	trf6151_compute_gain(exp_inp, target_bb);
 }
 
-void rffe_rx_win_ctrl(int16_t exp_inp, int16_t target_bb)
+void rffe_rx_win_ctrl(__unused int16_t exp_inp, __unused int16_t target_bb)
 {
+#warning function not implemented yet
 	/* FIXME */
 }
diff --git a/src/target/firmware/calypso/i2c.c b/src/target/firmware/calypso/i2c.c
index 02e1a03..cd05838 100644
--- a/src/target/firmware/calypso/i2c.c
+++ b/src/target/firmware/calypso/i2c.c
@@ -23,6 +23,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <i2c.h>
@@ -100,7 +101,7 @@ int i2c_write(uint8_t chip, uint32_t addr, int alen, const uint8_t *buffer, int
 	return 0;
 }
 
-void i2c_init(int speed, int slaveadd)
+void i2c_init(__unused int speed, __unused int slaveadd)
 {
 	/* scl_out = clk_func_ref / 3,
 	   clk_func_ref = master_clock_freq / (divisor_2 + 1)
diff --git a/src/target/firmware/calypso/sim.c b/src/target/firmware/calypso/sim.c
index 752628f..3f4dd15 100644
--- a/src/target/firmware/calypso/sim.c
+++ b/src/target/firmware/calypso/sim.c
@@ -27,6 +27,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <string.h>
@@ -392,7 +393,7 @@ int calypso_sim_transmit(uint8_t *data, int length)
 
 
 /* IRQ-Handler for simcard interface */
-void sim_irq_handler(enum irq_nr irq)
+void sim_irq_handler(__unused enum irq_nr irq)
 {
 	int regVal = readw(REG_SIM_IT);
 
diff --git a/src/target/firmware/comm/msgb.c b/src/target/firmware/comm/msgb.c
index 4215d24..f2ff8c1 100644
--- a/src/target/firmware/comm/msgb.c
+++ b/src/target/firmware/comm/msgb.c
@@ -24,8 +24,10 @@
 #include <sys/types.h>
 #include <asm/system.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <delay.h>
+#include <console.h>
 
 #include <osmocom/core/msgb.h>
 
@@ -43,7 +45,7 @@ struct supermsg {
 	uint8_t buf[MSGB_DATA_SIZE];
 };
 static struct supermsg msgs[MSGB_NUM];
-void *_talloc_zero(void *ctx, unsigned int size, const char *name)
+void *_talloc_zero(__unused void *ctx, unsigned int size, __unused const char *name)
 {
 	unsigned long flags;
 	unsigned int i;
diff --git a/src/target/firmware/comm/timer.c b/src/target/firmware/comm/timer.c
index 6a649ae..66b01b1 100644
--- a/src/target/firmware/comm/timer.c
+++ b/src/target/firmware/comm/timer.c
@@ -19,6 +19,8 @@
  */
 
 #include <stdint.h>
+
+#include <defines.h>
 #include <debug.h>
 #include <osmocom/core/linuxlist.h>
 
@@ -187,7 +189,7 @@ int timer_check(void)
 	return i;
 }
 
-static void timer_irq(enum irq_nr irq)
+static void timer_irq(__unused enum irq_nr irq)
 {
 	/* we only increment jiffies here.  FIXME: does this need to be atomic? */
 	jiffies++;
diff --git a/src/target/firmware/display/ssd1783.c b/src/target/firmware/display/ssd1783.c
index 5696b48..7f96c1e 100644
--- a/src/target/firmware/display/ssd1783.c
+++ b/src/target/firmware/display/ssd1783.c
@@ -24,6 +24,7 @@
 #include <stdint.h>
 #include <stdio.h>
 //#define DEBUG
+#include <defines.h>
 #include <debug.h>
 #include <delay.h>
 #include <uwire.h>
@@ -230,8 +231,9 @@ static int ssd1783_puts_col(const char *str, int txtline, int fColor, int bColor
 
 /* interface to display driver core */
 
-static void ssd1783_set_attr(unsigned long attr)
+static void ssd1783_set_attr(__unused unsigned long attr)
 {
+#warning function not implemented yet
 	/* FIXME */
 }
 
diff --git a/src/target/firmware/display/ssd1963.c b/src/target/firmware/display/ssd1963.c
index 49d5275..7c453a5 100644
--- a/src/target/firmware/display/ssd1963.c
+++ b/src/target/firmware/display/ssd1963.c
@@ -24,6 +24,7 @@
 
 #include <stdint.h>
 #include <stdio.h>
+#include <defines.h>
 #include <debug.h>
 #include <delay.h>
 #include <uwire.h>
@@ -78,8 +79,6 @@ static void ssd1963_clrscr(void)
 
 static void ssd1963_init(void)
 {
-	unsigned int i;
-
 	calypso_reset_set(RESET_EXT, 0);
 	uwire_init();
 	delay_ms(3);
@@ -183,8 +182,9 @@ static int ssd1963_puts_col(const char *str, int txtline, int fColor, int bColor
 
 /* interface to display driver core */
 
-static void ssd1963_set_attr(unsigned long attr)
+static void ssd1963_set_attr(__unused unsigned long attr)
 {
+#warning function not implemented yet
 	/* FIXME */
 }
 
diff --git a/src/target/firmware/display/td014.c b/src/target/firmware/display/td014.c
index 11ef3ea..df04c13 100644
--- a/src/target/firmware/display/td014.c
+++ b/src/target/firmware/display/td014.c
@@ -24,6 +24,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <delay.h>
 #include <uwire.h>
@@ -158,8 +159,9 @@ static int td014_puts_col(const char *str, int txtline, int fColor, int bColor)
 
 /* interface to display driver core */
 
-static void td014_set_attr(unsigned long attr)
+static void td014_set_attr(__unused unsigned long attr)
 {
+#warning function not implemented yet
 	/* FIXME */
 }
 
diff --git a/src/target/firmware/flash/cfi_flash.c b/src/target/firmware/flash/cfi_flash.c
index 4f31d78..167cf20 100644
--- a/src/target/firmware/flash/cfi_flash.c
+++ b/src/target/firmware/flash/cfi_flash.c
@@ -140,6 +140,9 @@ static inline uint16_t flash_read16(const void *base_addr, uint32_t offset)
 __ramtext
 static char flash_protected(uint32_t block_offset)
 {
+	/* prevent compiler from complaining when preprocessor causes
+	   variable block_offset to be unused */
+	(void)block_offset;
 #ifdef CONFIG_FLASH_WRITE
 #  ifdef CONFIG_FLASH_WRITE_LOADER
 	return 0;
diff --git a/src/target/firmware/layer1/afc.c b/src/target/firmware/layer1/afc.c
index a51a107..f136ef1 100644
--- a/src/target/firmware/layer1/afc.c
+++ b/src/target/firmware/layer1/afc.c
@@ -23,6 +23,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <osmocom/gsm/gsm_utils.h>
 
@@ -117,7 +118,7 @@ void afc_input(int32_t freq_error, uint16_t arfcn, int valid)
 }
 
 /* callback function for runavg */
-static void afc_ravg_output(struct running_avg *ravg, int32_t avg)
+static void afc_ravg_output(__unused struct running_avg *ravg, int32_t avg)
 {
 	afc_correct(avg, afc_state.arfcn);
 }
diff --git a/src/target/firmware/layer1/apc.c b/src/target/firmware/layer1/apc.c
index 480c760..c3180d3 100644
--- a/src/target/firmware/layer1/apc.c
+++ b/src/target/firmware/layer1/apc.c
@@ -22,6 +22,8 @@
 
 #include <errno.h>
 
+#include <defines.h>
+
 #include <osmocom/core/utils.h>
 #include <osmocom/gsm/gsm_utils.h>
 
@@ -33,7 +35,7 @@ extern const int dbm2apc_gsm900_max;
 
 
 /* determine the AUXAPC value by the Tx Power Level */
-int16_t apc_tx_dbm2auxapc(enum gsm_band band, int8_t dbm)
+int16_t apc_tx_dbm2auxapc(__unused enum gsm_band band, int8_t dbm)
 {
 	if (dbm < 0)
 		return -ERANGE;
diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c
index ed43e14..fd4ad09 100644
--- a/src/target/firmware/layer1/l23_api.c
+++ b/src/target/firmware/layer1/l23_api.c
@@ -26,6 +26,7 @@
 #include <stdio.h>
 #include <string.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <byteorder.h>
 
@@ -302,11 +303,8 @@ static void l1ctl_rx_crypto_req(struct msgb *msg)
 }
 
 /* receive a L1CTL_DM_REL_REQ from L23 */
-static void l1ctl_rx_dm_rel_req(struct msgb *msg)
+static void l1ctl_rx_dm_rel_req(__unused struct msgb *msg)
 {
-	struct l1ctl_hdr *l1h = (struct l1ctl_hdr *) msg->data;
-	struct l1ctl_info_ul *ul = (struct l1ctl_info_ul *) l1h->data;
-
 	printd("L1CTL_DM_REL_REQ\n");
 	l1a_mftask_set(0);
 	l1s.dedicated.type = GSM_DCHAN_NONE;
@@ -574,7 +572,7 @@ static void l1ctl_sim_req(struct msgb *msg)
 }
 
 /* callback from SERCOMM when L2 sends a message to L1 */
-static void l1a_l23_rx_cb(uint8_t dlci, struct msgb *msg)
+static void l1a_l23_rx_cb(__unused uint8_t dlci, struct msgb *msg)
 {
 	struct l1ctl_hdr *l1h = (struct l1ctl_hdr *) msg->data;
 
diff --git a/src/target/firmware/layer1/prim_fbsb.c b/src/target/firmware/layer1/prim_fbsb.c
index 023902d..06ecee2 100644
--- a/src/target/firmware/layer1/prim_fbsb.c
+++ b/src/target/firmware/layer1/prim_fbsb.c
@@ -178,8 +178,6 @@ static int l1s_sbdet_resp(__unused uint8_t p1, uint8_t attempt,
 	int qbits, fn_offset;
 	struct l1_cell_info *cinfo = &l1s.serving_cell;
 	int fnr_delta, bits_delta;
-	struct l1ctl_sync_new_ccch_resp *l1;
-	struct msgb *msg;
 
 	putchart('s');
 
@@ -327,7 +325,7 @@ static int read_fb_result(struct mon_state *st, int attempt)
 }
 
 static void fbinfo2cellinfo(struct l1_cell_info *cinfo,
-			    const struct mon_state *mon)
+			    __unused const struct mon_state *mon)
 {
 	int ntdma, qbits, fn_offset, fnr_delta, bits_delta;
 
@@ -523,8 +521,6 @@ static const struct tdma_sched_item fb_sched_set[] = {
 /* Asynchronous completion handler for FB detection */
 static void l1a_fb_compl(__unused enum l1_compl c)
 {
-	struct l1_cell_info *cinfo = &l1s.serving_cell;
-
 	if (last_fb->attempt >= 13) {
 		/* FB detection failed, signal this via L1CTL */
 		return l1ctl_fbsb_resp(255);
diff --git a/src/target/firmware/layer1/prim_rach.c b/src/target/firmware/layer1/prim_rach.c
index 47f7424..f0c553e 100644
--- a/src/target/firmware/layer1/prim_rach.c
+++ b/src/target/firmware/layer1/prim_rach.c
@@ -57,7 +57,6 @@ struct {
 /* p1: type of operation (0: one NB, 1: one RACH burst, 2: four NB */
 static int l1s_tx_rach_cmd(__unused uint8_t p1, __unused uint8_t p2, __unused uint16_t p3)
 {
-	int i;
 	uint16_t  *info_ptr;
 	uint8_t data[2];
 
diff --git a/src/target/firmware/layer1/prim_tch.c b/src/target/firmware/layer1/prim_tch.c
index 96858fb..e5f6a5a 100644
--- a/src/target/firmware/layer1/prim_tch.c
+++ b/src/target/firmware/layer1/prim_tch.c
@@ -500,7 +500,7 @@ const struct tdma_sched_item tch_sched_set[] = {
 /* This task is needed to perform some operation in the DSP when there is
  * no data to be exchanged */
 
-static int l1s_tch_d_resp(__unused uint8_t p1, __unused uint8_t p2, uint16_t p3)
+static int l1s_tch_d_resp(__unused uint8_t p1, __unused uint8_t p2, __unused uint16_t p3)
 {
 	/* mark READ page as being used */
 	dsp_api.r_page_used = 1;
diff --git a/src/target/firmware/layer1/prim_tx_nb.c b/src/target/firmware/layer1/prim_tx_nb.c
index 3038178..b886200 100644
--- a/src/target/firmware/layer1/prim_tx_nb.c
+++ b/src/target/firmware/layer1/prim_tx_nb.c
@@ -75,7 +75,6 @@ static int l1s_tx_cmd(uint8_t p1, uint8_t burst_id, uint16_t p3)
 {
 	uint16_t arfcn;
 	uint8_t tsc, tn;
-	uint8_t mf_task_id = p3 & 0xff;
 	uint8_t mf_task_flags = p3 >> 8;
 
 	putchart('T');
diff --git a/src/target/firmware/layer1/toa.c b/src/target/firmware/layer1/toa.c
index 7d80d95..e5b857c 100644
--- a/src/target/firmware/layer1/toa.c
+++ b/src/target/firmware/layer1/toa.c
@@ -24,6 +24,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <osmocom/gsm/gsm_utils.h>
 
@@ -71,7 +72,7 @@ void toa_reset(void)
 }
 
 /* callback function for runavg */
-static void toa_ravg_output(struct running_avg *ravg, int32_t avg)
+static void toa_ravg_output(__unused struct running_avg *ravg, int32_t avg)
 {
 	if (avg != 16) {
 		printf("TOA AVG is not 16 qbits, correcting (got %ld)\n", avg);
diff --git a/src/target/firmware/layer1/tpu_window.c b/src/target/firmware/layer1/tpu_window.c
index 2fdb048..e8762d4 100644
--- a/src/target/firmware/layer1/tpu_window.c
+++ b/src/target/firmware/layer1/tpu_window.c
@@ -135,7 +135,7 @@ void l1s_rx_win_ctrl(uint16_t arfcn, enum l1_rxwin_type wtype, uint8_t tn_ofs)
 	trf6151_set_mode(TRF6151_IDLE);
 }
 
-void l1s_tx_win_ctrl(uint16_t arfcn, enum l1_txwin_type wtype, uint8_t pwr, uint8_t tn_ofs)
+void l1s_tx_win_ctrl(uint16_t arfcn, enum l1_txwin_type wtype, __unused uint8_t pwr, uint8_t tn_ofs)
 {
 	uint16_t offset;
 
diff --git a/src/target/firmware/rf/trf6151.c b/src/target/firmware/rf/trf6151.c
index 5360402..29dd408 100644
--- a/src/target/firmware/rf/trf6151.c
+++ b/src/target/firmware/rf/trf6151.c
@@ -23,6 +23,7 @@
 #include <stdint.h>
 #include <stdio.h>
 
+#include <defines.h>
 #include <debug.h>
 #include <memory.h>
 #include <keypad.h>
@@ -568,6 +569,11 @@ void trf6151_rx_window(int16_t start_qbits, uint16_t arfcn)
 /* prepare a Tx window with the TRF6151 finished at time 'start' (in qbits) */
 void trf6151_tx_window(int16_t start_qbits, uint16_t arfcn)
 {
+	/* prevent compiler from complaining when preprocessor causes
+	   variables start_qbits and arfcn to be unused */
+	(void)start_qbits;
+	(void)arfcn;
+
 #ifdef CONFIG_TX_ENABLE
 	int16_t start_pll_qbits;
 
-- 
1.7.8.rc1




From alexander.huemer at xx.vu  Wed Nov 23 22:59:39 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:39 +0100
Subject: [PATCH 3/8] firmware: initialize variables
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-4-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warnings
warning: ??? may be used uninitialized in this function
warning: ??? is used uninitialized in this function
---
 src/target/firmware/apps/loader/main.c     |    2 +-
 src/target/firmware/apps/loader_mtk/main.c |    2 +-
 src/target/firmware/layer1/l23_api.c       |    2 +-
 src/target/firmware/layer1/mframe_sched.c  |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c
index 18f0b36..de2193a 100644
--- a/src/target/firmware/apps/loader/main.c
+++ b/src/target/firmware/apps/loader/main.c
@@ -204,7 +204,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg)
 
 	uint8_t command = msgb_get_u8(msg);
 
-	int res;
+	int res = 0;
 
 	flash_lock_t lock;
 
diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c
index 9bfaa7e..0bc4ab8 100644
--- a/src/target/firmware/apps/loader_mtk/main.c
+++ b/src/target/firmware/apps/loader_mtk/main.c
@@ -145,7 +145,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg)
 
 	uint8_t command = msgb_get_u8(msg);
 
-	int res;
+	int res = 0;
 
 	flash_lock_t lock;
 
diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c
index fd4ad09..bd990bb 100644
--- a/src/target/firmware/layer1/l23_api.c
+++ b/src/target/firmware/layer1/l23_api.c
@@ -69,7 +69,7 @@ static uint32_t chan_nr2mf_task_mask(uint8_t chan_nr, uint8_t neigh_mode)
 	uint8_t lch_idx;
 	enum mframe_task master_task = 0;
 	uint32_t neigh_task = 0;
-	enum mf_type multiframe;
+	enum mf_type multiframe = MFNONE;
 
 	if (cbits == 0x01) {
 		lch_idx = 0;
diff --git a/src/target/firmware/layer1/mframe_sched.c b/src/target/firmware/layer1/mframe_sched.c
index 6281c3d..5227d41 100644
--- a/src/target/firmware/layer1/mframe_sched.c
+++ b/src/target/firmware/layer1/mframe_sched.c
@@ -332,7 +332,7 @@ static const struct mframe_sched_item *sched_set_for_task[32] = {
 /* encodes a channel number according to 08.58 Chapter 9.3.1 */
 uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts)
 {
-	uint8_t cbits;
+	uint8_t cbits = 0;
 
 	switch (mft) {
 	case MF_TASK_BCCH_NORM:
-- 
1.7.8.rc1




From holger at freyther.de  Wed Nov 23 23:07:23 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 24 Nov 2011 00:07:23 +0100
Subject: [PATCH 3/8] firmware: initialize variables
In-Reply-To: <1322089184-27512-4-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-4-git-send-email-alexander.huemer@xx.vu>
Message-ID: <4ECD7CAB.9010201@freyther.de>

On 11/23/2011 11:59 PM, Alexander Huemer wrote:

> +++ b/src/target/firmware/layer1/mframe_sched.c
> @@ -332,7 +332,7 @@ static const struct mframe_sched_item *sched_set_for_task[32] = {
>  /* encodes a channel number according to 08.58 Chapter 9.3.1 */
>  uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts)
>  {
> -	uint8_t cbits;
> +	uint8_t cbits = 0;
>  
>  	switch (mft) {
>  	case MF_TASK_BCCH_NORM:

uninitialized variables are tricky. In this case it is more the question of
which enum value is not handled in the switch/case statement (or if the gcc
fails to look at all values of the enum).
E.g. a

default:
  cbits = 0;
  BIG_WARNING(mft);

might be better?



From alexander.huemer at xx.vu  Wed Nov 23 23:41:56 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Thu, 24 Nov 2011 00:41:56 +0100
Subject: [PATCH 3/8] firmware: initialize variables
In-Reply-To: <4ECD7CAB.9010201@freyther.de>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-4-git-send-email-alexander.huemer@xx.vu>
	<4ECD7CAB.9010201@freyther.de>
Message-ID: <20111123234156.GA21889@de.xx.vu>

On Thu, Nov 24, 2011 at 12:07:23AM +0100, Holger Hans Peter Freyther wrote:
> On 11/23/2011 11:59 PM, Alexander Huemer wrote:
> 
> > +++ b/src/target/firmware/layer1/mframe_sched.c
> > @@ -332,7 +332,7 @@ static const struct mframe_sched_item *sched_set_for_task[32] = {
> >  /* encodes a channel number according to 08.58 Chapter 9.3.1 */
> >  uint8_t mframe_task2chan_nr(enum mframe_task mft, uint8_t ts)
> >  {
> > -	uint8_t cbits;
> > +	uint8_t cbits = 0;
> >  
> >  	switch (mft) {
> >  	case MF_TASK_BCCH_NORM:
> 
> uninitialized variables are tricky. In this case it is more the question of
> which enum value is not handled in the switch/case statement (or if the gcc
> fails to look at all values of the enum).
> E.g. a
> 
> default:
>   cbits = 0;
>   BIG_WARNING(mft);
> 
> might be better?
> 
i am a bit unsure about the best way to handle such stuff. default cases
have the drawback that gcc does not tell you any more that enum values
are not handled in the switch. so i try to avoid default cases on enums.



From holger at freyther.de  Wed Nov 23 23:43:28 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 24 Nov 2011 00:43:28 +0100
Subject: [PATCH 3/8] firmware: initialize variables
In-Reply-To: <20111123234156.GA21889@de.xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-4-git-send-email-alexander.huemer@xx.vu>
	<4ECD7CAB.9010201@freyther.de> <20111123234156.GA21889@de.xx.vu>
Message-ID: <4ECD8520.9090404@freyther.de>

On 11/24/2011 12:41 AM, Alexander Huemer wrote:
> On Thu, Nov 24, 2011 at 12:07:23AM +0100, Holger Hans Peter Freyther wrote:
>> On 11/23/2011 11:59 PM, Alexander Huemer wrote:

>>
> i am a bit unsure about the best way to handle such stuff. default cases
> have the drawback that gcc does not tell you any more that enum values
> are not handled in the switch. so i try to avoid default cases on enums.

well,
a) we have a warning
b) we initialize cbits and shut the compiler up but still miss some case values.
c) we add a default: with a runtime warning..

I tend to prefer a) and c) over b).




From alexander.huemer at xx.vu  Wed Nov 23 22:59:40 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:40 +0100
Subject: [PATCH 4/8] firmware: correct pointer inits and assignments
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-5-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warnings
warning: initialization from incompatible pointer type
warning: assignment from incompatible pointer type
---
 src/target/firmware/apps/loader/main.c     |    2 +-
 src/target/firmware/apps/loader_mtk/main.c |    2 +-
 src/target/firmware/display/ssd1783.c      |    2 +-
 src/target/firmware/display/ssd1963.c      |    2 +-
 src/target/firmware/display/td014.c        |    2 +-
 src/target/firmware/layer1/prim_pm.c       |    4 ++--
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c
index de2193a..602297b 100644
--- a/src/target/firmware/apps/loader/main.c
+++ b/src/target/firmware/apps/loader/main.c
@@ -308,7 +308,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg)
 		msgb_put_u8(reply, 1);	// nchips
 
 		// chip 1
-		msgb_put_u32(reply, the_flash.f_base);
+		msgb_put_u32(reply, *(uint32_t *)the_flash.f_base);
 		msgb_put_u32(reply, the_flash.f_size);
 		msgb_put_u8(reply, the_flash.f_nregions);
 
diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c
index 0bc4ab8..4345443 100644
--- a/src/target/firmware/apps/loader_mtk/main.c
+++ b/src/target/firmware/apps/loader_mtk/main.c
@@ -249,7 +249,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg)
 		msgb_put_u8(reply, 1);	// nchips
 
 		// chip 1
-		msgb_put_u32(reply, the_flash.f_base);
+		msgb_put_u32(reply, *(uint32_t *)the_flash.f_base);
 		msgb_put_u32(reply, the_flash.f_size);
 		msgb_put_u8(reply, the_flash.f_nregions);
 
diff --git a/src/target/firmware/display/ssd1783.c b/src/target/firmware/display/ssd1783.c
index 7f96c1e..71c3cf3 100644
--- a/src/target/firmware/display/ssd1783.c
+++ b/src/target/firmware/display/ssd1783.c
@@ -237,7 +237,7 @@ static void ssd1783_set_attr(__unused unsigned long attr)
 	/* FIXME */
 }
 
-static int ssd1783_putc(unsigned int c)
+static int ssd1783_putc(unsigned char c)
 {
 	return ssd1783_putc_col(c, BLACK, WHITE);
 }
diff --git a/src/target/firmware/display/ssd1963.c b/src/target/firmware/display/ssd1963.c
index 7c453a5..0b2c49f 100644
--- a/src/target/firmware/display/ssd1963.c
+++ b/src/target/firmware/display/ssd1963.c
@@ -188,7 +188,7 @@ static void ssd1963_set_attr(__unused unsigned long attr)
 	/* FIXME */
 }
 
-static int ssd1963_putc(unsigned int c)
+static int ssd1963_putc(unsigned char c)
 {
 	return ssd1963_putc_col(c, BLACK, WHITE);
 }
diff --git a/src/target/firmware/display/td014.c b/src/target/firmware/display/td014.c
index df04c13..b4dd1c0 100644
--- a/src/target/firmware/display/td014.c
+++ b/src/target/firmware/display/td014.c
@@ -165,7 +165,7 @@ static void td014_set_attr(__unused unsigned long attr)
 	/* FIXME */
 }
 
-static int td014_putc(unsigned int c)
+static int td014_putc(unsigned char c)
 {
 	return td014_putc_col(c, BLACK, WHITE);
 }
diff --git a/src/target/firmware/layer1/prim_pm.c b/src/target/firmware/layer1/prim_pm.c
index c2d85ac..640f960 100644
--- a/src/target/firmware/layer1/prim_pm.c
+++ b/src/target/firmware/layer1/prim_pm.c
@@ -108,7 +108,7 @@ static int l1s_pm_resp(uint8_t num_meas, __unused uint8_t p2,
 		l1s.pm.msg = l1ctl_msgb_alloc(L1CTL_PM_CONF);
 	}
 
-	pmr = msgb_put(l1s.pm.msg, sizeof(*pmr));
+	pmr = (struct l1ctl_pm_conf *)msgb_put(l1s.pm.msg, sizeof(*pmr));
 	pmr->band_arfcn = htons(arfcn);
 	/* FIXME: do this as RxLev rather than DBM8 ? */
 	pmr->pm[0] = dbm2rxlev(agc_inp_dbm8_by_pm(pm_level[0])/8);
@@ -124,7 +124,7 @@ static int l1s_pm_resp(uint8_t num_meas, __unused uint8_t p2,
 			l1s.pm.range.arfcn_next++;
 		} else {
 			/* we have finished, flush the msgb to L2 */
-			struct l1ctl_hdr *l1h = l1s.pm.msg->l1h;
+			struct l1ctl_hdr *l1h = (struct l1ctl_hdr *)l1s.pm.msg->l1h;
 			l1h->flags |= L1CTL_F_DONE;
 			l1_queue_for_l2(l1s.pm.msg);
 			l1s.pm.msg = NULL;
-- 
1.7.8.rc1




From alexander.huemer at xx.vu  Wed Nov 23 22:59:41 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:41 +0100
Subject: [PATCH 5/8] firmware: correct signedness of comparisons
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-6-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warning
warning: comparison between signed and unsigned
---
 src/target/firmware/apps/loader/main.c |   10 +++++-----
 src/target/firmware/flash/cfi_flash.c  |    2 +-
 src/target/firmware/layer1/prim_pm.c   |    2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c
index 602297b..b4c51de 100644
--- a/src/target/firmware/apps/loader/main.c
+++ b/src/target/firmware/apps/loader/main.c
@@ -125,7 +125,7 @@ static const uint8_t phone_ack[] = { 0x1b, 0xf6, 0x02, 0x00, 0x41, 0x03, 0x42 };
 int main(void)
 {
 	/* Simulate a compal loader saying "ACK" */
-	int i = 0;
+	unsigned int i;
 	for (i = 0; i < sizeof(phone_ack); i++) {
 		putchar_asm(phone_ack[i]);
 	}
@@ -166,11 +166,11 @@ int main(void)
 		       the_flash.f_size, the_flash.f_base,
 		       the_flash.f_nregions);
 
-		int i;
-		for (i = 0; i < the_flash.f_nregions; i++) {
+		unsigned int j;
+		for (j = 0; j < the_flash.f_nregions; j++) {
 			printf("  Region %d of %zu pages with %zu bytes each.\n",
 			       i,
-			       the_flash.f_regions[i].fr_bnum,
+			       the_flash.f_regions[j].fr_bnum,
 			       the_flash.f_regions[i].fr_bsize);
 		}
 
@@ -312,7 +312,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg)
 		msgb_put_u32(reply, the_flash.f_size);
 		msgb_put_u8(reply, the_flash.f_nregions);
 
-		int i;
+		unsigned int 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);
diff --git a/src/target/firmware/flash/cfi_flash.c b/src/target/firmware/flash/cfi_flash.c
index 167cf20..eaaedff 100644
--- a/src/target/firmware/flash/cfi_flash.c
+++ b/src/target/firmware/flash/cfi_flash.c
@@ -402,7 +402,7 @@ __ramtext
 static int get_query(void *base_addr, struct cfi_query *query)
 {
 	int res = 0;
-	int i;
+	unsigned int i;
 
 	flash_write_cmd(base_addr, CFI_CMD_CFI);
 
diff --git a/src/target/firmware/layer1/prim_pm.c b/src/target/firmware/layer1/prim_pm.c
index 640f960..54a6780 100644
--- a/src/target/firmware/layer1/prim_pm.c
+++ b/src/target/firmware/layer1/prim_pm.c
@@ -101,7 +101,7 @@ static int l1s_pm_resp(uint8_t num_meas, __unused uint8_t p2,
 	if (!l1s.pm.msg)
 		l1s.pm.msg = l1ctl_msgb_alloc(L1CTL_PM_CONF);
 
-	if (msgb_tailroom(l1s.pm.msg) < sizeof(*pmr)) {
+	if (msgb_tailroom(l1s.pm.msg) < (int)sizeof(*pmr)) {
 		/* flush current msgb */
 		l1_queue_for_l2(l1s.pm.msg);
 		/* allocate a new msgb and initialize header */
-- 
1.7.8.rc1




From alexander.huemer at xx.vu  Wed Nov 23 22:59:42 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:42 +0100
Subject: [PATCH 6/8] firmware: don't compile unused static functions
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-7-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warning
warning: ??? defined but not used
---
 src/target/firmware/calypso/dsp.c |    2 ++
 src/target/firmware/calypso/irq.c |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/target/firmware/calypso/dsp.c b/src/target/firmware/calypso/dsp.c
index 8bf9749..470dfc4 100644
--- a/src/target/firmware/calypso/dsp.c
+++ b/src/target/firmware/calypso/dsp.c
@@ -117,6 +117,7 @@ static void dsp_bl_start_at(uint16_t addr)
 	writew(BL_CMD_COPY_BLOCK, BL_CMD_STATUS);
 }
 
+#if 0
 static int dsp_bl_upload_sections(const struct dsp_section *sec)
 {
 	/* Make sure the bootloader is ready */
@@ -151,6 +152,7 @@ static int dsp_bl_upload_sections(const struct dsp_section *sec)
 
 	return 0;
 }
+#endif
 
 static int dsp_upload_sections_api(const struct dsp_section *sec, uint16_t dsp_base_api)
 {
diff --git a/src/target/firmware/calypso/irq.c b/src/target/firmware/calypso/irq.c
index 136fd55..9c2e0ed 100644
--- a/src/target/firmware/calypso/irq.c
+++ b/src/target/firmware/calypso/irq.c
@@ -232,6 +232,7 @@ static void set_default_priorities(void)
 	}
 }
 
+#if 0
 static uint32_t irq_nest_mask;
 /* mask off all interrupts that have a lower priority than irq_nr */
 static void mask_all_lower_prio_irqs(enum irq_nr irqnr)
@@ -250,6 +251,7 @@ static void mask_all_lower_prio_irqs(enum irq_nr irqnr)
 			irq_nest_mask |= (1 << i);
 	}
 }
+#endif
 
 void irq_init(void)
 {
-- 
1.7.8.rc1




From alexander.huemer at xx.vu  Wed Nov 23 22:59:43 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:43 +0100
Subject: [PATCH 7/8] firmware: correct function declarations
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-8-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warnings
warning: implicit declaration of function ???
warning: redundant redeclaration of ???
---
 src/target/firmware/apps/chainload/main.c   |    1 +
 src/target/firmware/apps/loader/main.c      |    1 +
 src/target/firmware/board/compal_e86/init.c |    1 +
 src/target/firmware/board/compal_e99/init.c |    1 +
 src/target/firmware/board/se_j100/init.c    |    1 +
 src/target/firmware/include/layer1/async.h  |    8 ++------
 src/target/firmware/include/layer1/prim.h   |    2 ++
 src/target/firmware/layer1/l23_api.c        |    4 ++--
 src/target/firmware/layer1/prim_fbsb.c      |    2 ++
 src/target/firmware/layer1/prim_freq.c      |    1 +
 src/target/firmware/layer1/prim_rach.c      |    1 +
 src/target/firmware/layer1/prim_rx_nb.c     |    2 ++
 src/target/firmware/layer1/tpu_window.c     |    1 +
 13 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/src/target/firmware/apps/chainload/main.c b/src/target/firmware/apps/chainload/main.c
index 5121837..9dfa217 100644
--- a/src/target/firmware/apps/chainload/main.c
+++ b/src/target/firmware/apps/chainload/main.c
@@ -29,6 +29,7 @@
 #include <delay.h>
 
 #include <calypso/clock.h>
+#include <calypso/timer.h>
 
 /* Main Program */
 
diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c
index b4c51de..4ff3b6a 100644
--- a/src/target/firmware/apps/loader/main.c
+++ b/src/target/firmware/apps/loader/main.c
@@ -47,6 +47,7 @@
 #include <calypso/misc.h>
 #include <uart.h>
 #include <calypso/timer.h>
+#include <calypso/backlight.h>
 
 #include <flash/cfi_flash.h>
 
diff --git a/src/target/firmware/board/compal_e86/init.c b/src/target/firmware/board/compal_e86/init.c
index 1de6193..9dbda0e 100644
--- a/src/target/firmware/board/compal_e86/init.c
+++ b/src/target/firmware/board/compal_e86/init.c
@@ -41,6 +41,7 @@
 #include <calypso/backlight.h>
 
 #include <comm/sercomm.h>
+#include <comm/timer.h>
 
 #include <abb/twl3025.h>
 #include <rf/trf6151.h>
diff --git a/src/target/firmware/board/compal_e99/init.c b/src/target/firmware/board/compal_e99/init.c
index 0c218a8..1c76749 100644
--- a/src/target/firmware/board/compal_e99/init.c
+++ b/src/target/firmware/board/compal_e99/init.c
@@ -41,6 +41,7 @@
 #include <calypso/backlight.h>
 
 #include <comm/sercomm.h>
+#include <comm/timer.h>
 
 #include <abb/twl3025.h>
 #include <rf/trf6151.h>
diff --git a/src/target/firmware/board/se_j100/init.c b/src/target/firmware/board/se_j100/init.c
index 30c3e6b..e8691cf 100644
--- a/src/target/firmware/board/se_j100/init.c
+++ b/src/target/firmware/board/se_j100/init.c
@@ -41,6 +41,7 @@
 #include <calypso/backlight.h>
 
 #include <comm/sercomm.h>
+#include <comm/timer.h>
 
 #include <abb/twl3025.h>
 #include <rf/trf6151.h>
diff --git a/src/target/firmware/include/layer1/async.h b/src/target/firmware/include/layer1/async.h
index a9fa08d..0935ec3 100644
--- a/src/target/firmware/include/layer1/async.h
+++ b/src/target/firmware/include/layer1/async.h
@@ -32,18 +32,14 @@ int l1a_txq_msgb_count(struct llist_head *queue);
 /* flush all pending msgb */
 void l1a_txq_msgb_flush(struct llist_head *queue);
 
-/* request a RACH */
-void l1a_rach_req(uint16_t offset, uint8_t combined, uint8_t ra);
-
-/* schedule frequency change */
-void l1a_freq_req(uint32_t fn_sched);
-
 /* Enable a repeating multiframe task */
 void l1a_mftask_enable(enum mframe_task task);
 
 /* Disable a repeating multiframe task */
 void l1a_mftask_disable(enum mframe_task task);
 
+void l1a_mftask_set(uint32_t tasks);
+
 /* Set TCH mode */
 uint8_t l1a_tch_mode_set(uint8_t mode);
 
diff --git a/src/target/firmware/include/layer1/prim.h b/src/target/firmware/include/layer1/prim.h
index 30c51ae..f01d64e 100644
--- a/src/target/firmware/include/layer1/prim.h
+++ b/src/target/firmware/include/layer1/prim.h
@@ -19,7 +19,9 @@ void l1s_pm_test(uint8_t base_fn, uint16_t arfcn);
 void l1s_nb_test(uint8_t base_fn);
 
 void l1s_fbsb_req(uint8_t base_fn, struct l1ctl_fbsb_req *req);
+/* schedule frequency change */
 void l1a_freq_req(uint32_t fn_sched);
+/* request a RACH */
 void l1a_rach_req(uint16_t offset, uint8_t combined, uint8_t ra);
 
 /* Primitives raw scheduling sets */
diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c
index bd990bb..b21d8f0 100644
--- a/src/target/firmware/layer1/l23_api.c
+++ b/src/target/firmware/layer1/l23_api.c
@@ -39,10 +39,12 @@
 #include <layer1/mframe_sched.h>
 #include <layer1/prim.h>
 #include <layer1/tpu_window.h>
+#include <layer1/sched_gsmtime.h>
 
 #include <abb/twl3025.h>
 #include <rf/trf6151.h>
 #include <calypso/sim.h>
+#include <calypso/dsp.h>
 
 #include <l1ctl_proto.h>
 
@@ -551,8 +553,6 @@ static void l1ctl_rx_traffic_req(struct msgb *msg)
 	l1a_txq_msgb_enq(&l1s.tx_queue[L1S_CHAN_TRAFFIC], msg);
 }
 
-void sim_apdu(uint16_t len, uint8_t *data);
-
 static void l1ctl_sim_req(struct msgb *msg)
 {
 	uint16_t len = msg->len - sizeof(struct l1ctl_hdr);
diff --git a/src/target/firmware/layer1/prim_fbsb.c b/src/target/firmware/layer1/prim_fbsb.c
index 06ecee2..936afbc 100644
--- a/src/target/firmware/layer1/prim_fbsb.c
+++ b/src/target/firmware/layer1/prim_fbsb.c
@@ -31,6 +31,7 @@
 #include <debug.h>
 #include <memory.h>
 #include <byteorder.h>
+#include <rffe.h>
 #include <osmocom/gsm/gsm_utils.h>
 #include <osmocom/core/msgb.h>
 #include <calypso/dsp_api.h>
@@ -48,6 +49,7 @@
 #include <layer1/mframe_sched.h>
 #include <layer1/tpu_window.h>
 #include <layer1/l23_api.h>
+#include <layer1/agc.h>
 
 #include <l1ctl_proto.h>
 
diff --git a/src/target/firmware/layer1/prim_freq.c b/src/target/firmware/layer1/prim_freq.c
index 64e08b5..057caa7 100644
--- a/src/target/firmware/layer1/prim_freq.c
+++ b/src/target/firmware/layer1/prim_freq.c
@@ -46,6 +46,7 @@
 #include <layer1/tdma_sched.h>
 #include <layer1/tpu_window.h>
 #include <layer1/l23_api.h>
+#include <layer1/sched_gsmtime.h>
 
 #include <l1ctl_proto.h>
 
diff --git a/src/target/firmware/layer1/prim_rach.c b/src/target/firmware/layer1/prim_rach.c
index f0c553e..3825d7f 100644
--- a/src/target/firmware/layer1/prim_rach.c
+++ b/src/target/firmware/layer1/prim_rach.c
@@ -46,6 +46,7 @@
 #include <layer1/tdma_sched.h>
 #include <layer1/tpu_window.h>
 #include <layer1/l23_api.h>
+#include <layer1/sched_gsmtime.h>
 
 #include <l1ctl_proto.h>
 
diff --git a/src/target/firmware/layer1/prim_rx_nb.c b/src/target/firmware/layer1/prim_rx_nb.c
index 7eb4548..ade23a0 100644
--- a/src/target/firmware/layer1/prim_rx_nb.c
+++ b/src/target/firmware/layer1/prim_rx_nb.c
@@ -29,6 +29,7 @@
 #include <debug.h>
 #include <memory.h>
 #include <byteorder.h>
+#include <rffe.h>
 #include <osmocom/gsm/gsm_utils.h>
 #include <osmocom/core/msgb.h>
 #include <calypso/dsp_api.h>
@@ -48,6 +49,7 @@
 #include <layer1/l23_api.h>
 #include <layer1/rfch.h>
 #include <layer1/prim.h>
+#include <layer1/agc.h>
 
 #include <l1ctl_proto.h>
 
diff --git a/src/target/firmware/layer1/tpu_window.c b/src/target/firmware/layer1/tpu_window.c
index e8762d4..c5b4d63 100644
--- a/src/target/firmware/layer1/tpu_window.c
+++ b/src/target/firmware/layer1/tpu_window.c
@@ -33,6 +33,7 @@
 
 #include <layer1/sync.h>
 #include <layer1/tpu_window.h>
+#include <layer1/rfch.h>
 
 /* all units in GSM quarter-bits (923.1ns) */
 #define L1_TDMA_LENGTH_Q	5000
-- 
1.7.8.rc1




From juantxipazos at yahoo.es  Mon Nov 28 23:18:10 2011
From: juantxipazos at yahoo.es (Juantxi)
Date: Tue, 29 Nov 2011 00:18:10 +0100
Subject: small problem
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-8-git-send-email-alexander.huemer@xx.vu>
Message-ID: <E317F36D6A484576B3C2E5FE1195D42F@Maite>

osmocom-bb\src\host\layer23\include\l1ctl_proto.h

git 1.7.4.msysgit.0
00000000   2E 2E 2F 2E 2E 2F 2E 2E  2F 2E 2E 2F 69 6E 63 6C
../../../../incl
00000016   75 64 65 2F 6C 31 63 74  6C 5F 70 72 6F 74 6F 2E
ude/l1ctl_proto.
00000032   68                                               h

change -> #include <../../../../include/l1ctl_proto.h>


git 1.7.5.1
00000000   21 3C 73 79 6D 6C 69 6E  6B 3E FF FE 2E 00 2E 00   !<symlink>??.
.
00000016   2F 00 2E 00 2E 00 2F 00  2E 00 2E 00 2F 00 2E 00   / . . / . . /
.
00000032   2E 00 2F 00 69 00 6E 00  63 00 6C 00 75 00 64 00   . / i n c l u
d
00000048   65 00 2F 00 6C 00 31 00  63 00 74 00 6C 00 5F 00   e / l 1 c t l
_
00000064   70 00 72 00 6F 00 74 00  6F 00 2E 00 68 00 00 00   p r o t o . h

error in git?


osmocom-bb\src\shared\libosmocore\src\socket.c
int osmo_sockaddr_is_local(struct sockaddr *addr, socklen_t addrlen)

osmocom-bb_win\src\shared\libosmocore\include\osmocom\core\socket.h
int osmo_sockaddr_is_local(struct sockaddr *addr, unsigned int addrlen);

change socket.c -> socklen_t -> unsigned int

         gcc 3.4.4
         g++ 4.5.3

error in gcc?

thank you




From laforge at gnumonks.org  Tue Nov 29 06:48:00 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 29 Nov 2011 07:48:00 +0100
Subject: small problem
In-Reply-To: <E317F36D6A484576B3C2E5FE1195D42F@Maite>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-8-git-send-email-alexander.huemer@xx.vu>
	<E317F36D6A484576B3C2E5FE1195D42F@Maite>
Message-ID: <20111129064800.GE5843@prithivi.gnumonks.org>

On Tue, Nov 29, 2011 at 12:18:10AM +0100, Juantxi wrote:

> change -> #include <../../../../include/l1ctl_proto.h>
> 
> 
> git 1.7.5.1
> 00000000   21 3C 73 79 6D 6C 69 6E  6B 3E FF FE 2E 00 2E 00   !<symlink>??.
> .
> 00000016   2F 00 2E 00 2E 00 2F 00  2E 00 2E 00 2F 00 2E 00   / . . / . . /
> .
> 00000032   2E 00 2F 00 69 00 6E 00  63 00 6C 00 75 00 64 00   . / i n c l u
> d
> 00000048   65 00 2F 00 6C 00 31 00  63 00 74 00 6C 00 5F 00   e / l 1 c t l
> _
> 00000064   70 00 72 00 6F 00 74 00  6F 00 2E 00 68 00 00 00   p r o t o . h
> 
> error in git?

I'm not sure how git deals with symbolik links on cygwin.  Sorry.

While some users have had success using cygwin, it is not a platform
that we support.  You're mostly on your own here, and should probably
have some experience with fixing up smaller issues related to the cygwin
API differences and how git behaves on your platform.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From juantxipazos at yahoo.es  Tue Nov 29 08:02:48 2011
From: juantxipazos at yahoo.es (Juantxi)
Date: Tue, 29 Nov 2011 09:02:48 +0100
Subject: small problem
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-8-git-send-email-alexander.huemer@xx.vu>
	<E317F36D6A484576B3C2E5FE1195D42F@Maite>
	<20111129064800.GE5843@prithivi.gnumonks.org>
Message-ID: <53BEABE19E8F48BB9F08CE8A1E3AE008@Maite>

> While some users have had success using cygwin, it is not a platform
> that we support.  You're mostly on your own here, and should probably
> have some experience with fixing up smaller issues related to the cygwin
> API differences and how git behaves on your platform.

compilation process using CygWin is OK!

need socket.c change:
int osmo_sockaddr_is_local(struct sockaddr *addr, unsigned int addrlen)


In linux use old slackware live cd
because I have only 1 laptop 256MB 20MB hard disk 800MHz
same versions are identical in cygwin other no

  autotool -> not install
  shtool   -> not install
  make 3.81 YES
  automake 1.11.1 YES
  libtool 2.4 YES
  pkg-config 0.23 YES
  autoconf 2.68 YES
  M4 1.4.16 - YES
  git 1.7.5.1 YES
  gcc 3.4.4 YES
  g++ 4.5.3 NO! older in wifislax 3.4.4
  gnuarm bu-2.17 gcc 4.1.1 NO! older in my linux gnuarm 3.4.3

my problem is:

"MAKE: no rules for handlers.p"

very rare! but ...

"continue in next weeks"

ja ja ja

good bye




From alexander.huemer at xx.vu  Wed Nov 23 22:59:44 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 23 Nov 2011 23:59:44 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>

this eliminates the occurrance of gcc warning
warning: cast increases required alignment of target type
---
 src/target/firmware/include/comm/timer.h           |    4 +++-
 src/target/firmware/include/layer1/sched_gsmtime.h |    5 ++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/target/firmware/include/comm/timer.h b/src/target/firmware/include/comm/timer.h
index db7d1a5..7025cda 100644
--- a/src/target/firmware/include/comm/timer.h
+++ b/src/target/firmware/include/comm/timer.h
@@ -21,6 +21,8 @@
 #ifndef TIMER_H
 #define TIMER_H
 
+#include <defines.h>
+
 #include <sys/time.h>
 
 #include <osmocom/core/linuxlist.h>
@@ -51,7 +53,7 @@ struct osmo_timer_list {
 
 	void (*cb)(void*);
 	void *data;
-};
+} __packed;
 
 extern unsigned long volatile jiffies;
 
diff --git a/src/target/firmware/include/layer1/sched_gsmtime.h b/src/target/firmware/include/layer1/sched_gsmtime.h
index c40359e..36918fa 100644
--- a/src/target/firmware/include/layer1/sched_gsmtime.h
+++ b/src/target/firmware/include/layer1/sched_gsmtime.h
@@ -2,6 +2,9 @@
 #define _L1_SCHED_GSMTIME_H
 
 #include <stdint.h>
+
+#include <defines.h>
+
 #include <osmocom/core/linuxlist.h>
 
 struct sched_gsmtime_event {
@@ -9,7 +12,7 @@ struct sched_gsmtime_event {
 	const struct tdma_sched_item *si;
 	uint32_t fn;
 	uint16_t p3;	/* parameter for TDMA scheduler */
-};
+} __packed;
 
 /* initialize the GSMTIME scheduler */
 void sched_gsmtime_init(void);
-- 
1.7.8.rc1




From 246tnt at gmail.com  Thu Nov 24 06:58:33 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 24 Nov 2011 07:58:33 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>
Message-ID: <CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>

Hi,

First, thanks for this series of patch, I'll be sure to review and test them.

> this eliminates the occurrance of gcc warning
> warning: cast increases required alignment of target type
> ---
> ?src/target/firmware/include/comm/timer.h ? ? ? ? ? | ? ?4 +++-
> ?src/target/firmware/include/layer1/sched_gsmtime.h | ? ?5 ++++-
> ?2 files changed, 7 insertions(+), 2 deletions(-)

> -};
> +} __packed;

I'm not conviced by this one : Why should we use packed for structures
not used as 'communication packets' ?

Cheers,

     Sylvain



From laforge at gnumonks.org  Thu Nov 24 08:40:19 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Nov 2011 09:40:19 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>
	<CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
Message-ID: <20111124084019.GB23294@prithivi.gnumonks.org>

Hi Sylvain and Alexander,

On Thu, Nov 24, 2011 at 07:58:33AM +0100, Sylvain Munaut wrote:
> First, thanks for this series of patch, I'll be sure to review and test them.

Thanks for testing, Sylvain.

> > -};
> > +} __packed;
> 
> I'm not conviced by this one : Why should we use packed for structures
> not used as 'communication packets' ?

I agree with Sylvain here.  this will just cause the compiler to
generate much less efficient code at no other benefit...

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From alexander.huemer at xx.vu  Thu Nov 24 09:36:27 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Thu, 24 Nov 2011 10:36:27 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>
	<CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
Message-ID: <20111124093627.GC21889@de.xx.vu>

On Thu, Nov 24, 2011 at 07:58:33AM +0100, Sylvain Munaut wrote:
> Hi,
> 
> First, thanks for this series of patch, I'll be sure to review and test them.
> 
Well, no problem, I had some time on hand I couldn't use otherwise.
> > this eliminates the occurrance of gcc warning
> > warning: cast increases required alignment of target type
> > ---
> > ?src/target/firmware/include/comm/timer.h ? ? ? ? ? | ? ?4 +++-
> > ?src/target/firmware/include/layer1/sched_gsmtime.h | ? ?5 ++++-
> > ?2 files changed, 7 insertions(+), 2 deletions(-)
> 
> > -};
> > +} __packed;
> 
> I'm not conviced by this one : Why should we use packed for structures
> not used as 'communication packets' ?
> 
What are the drawbacks ?

Steve and Holger raised some reasonable concerns on some of the other
patches, it seems I was quite unconcentrated and they are mostly crap.
The patches do not contain any "magic" anyway. Just straight-forward
reaction on the different kind of warnings. Most of them can be
eliminated easily.

Kind regards
-Alex



From holger at freyther.de  Thu Nov 24 09:49:43 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 24 Nov 2011 10:49:43 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <20111124093627.GC21889@de.xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>	<1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>	<CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
	<20111124093627.GC21889@de.xx.vu>
Message-ID: <4ECE1337.3000604@freyther.de>

On 11/24/2011 10:36 AM, Alexander Huemer wrote:

> Steve and Holger raised some reasonable concerns on some of the other
> patches, it seems I was quite unconcentrated and they are mostly crap.

crap? no, not at all. I agree that we should get the number of warnings down,
sometimes a warning just needs something else than the straight forward fix.




From alexander.huemer at xx.vu  Thu Nov 24 10:36:47 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Thu, 24 Nov 2011 11:36:47 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <4ECE1337.3000604@freyther.de>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>
	<CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
	<20111124093627.GC21889@de.xx.vu> <4ECE1337.3000604@freyther.de>
Message-ID: <20111124103647.GD21889@de.xx.vu>

On Thu, Nov 24, 2011 at 10:49:43AM +0100, Holger Hans Peter Freyther wrote:
> On 11/24/2011 10:36 AM, Alexander Huemer wrote:
> 
> > Steve and Holger raised some reasonable concerns on some of the other
> > patches, it seems I was quite unconcentrated and they are mostly crap.
> 
> crap? no, not at all. I agree that we should get the number of warnings down,
> sometimes a warning just needs something else than the straight forward fix.
> 
Compiler warnings are of course controversial.
I personally think that osmocom-bb and friends are fine pieces of code
and deserve a kind of "polished" look when compiling.

Some warnings are also quite strong indications of bugs like "... makes
pointer from integer without a cast" and things like that.

I myself don't know how to handle e.g. "discards qualifiers from pointer
target type" when the constness of lvalue and rvalue don't match.

Maybe it doesn't actually matter so much and I am just pedantic.



From laforge at gnumonks.org  Thu Nov 24 10:33:09 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Nov 2011 11:33:09 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <20111124093627.GC21889@de.xx.vu>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>
	<CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
	<20111124093627.GC21889@de.xx.vu>
Message-ID: <20111124103309.GC23833@prithivi.gnumonks.org>

Hi Alexander,

On Thu, Nov 24, 2011 at 10:36:27AM +0100, Alexander Huemer wrote:
> On Thu, Nov 24, 2011 at 07:58:33AM +0100, Sylvain Munaut wrote:
> > Hi,
> > 
> > First, thanks for this series of patch, I'll be sure to review and test them.
> > 
> Well, no problem, I had some time on hand I couldn't use otherwise.
> > > this eliminates the occurrance of gcc warning
> > > warning: cast increases required alignment of target type
> > > ---
> > > ?src/target/firmware/include/comm/timer.h ? ? ? ? ? | ? ?4 +++-
> > > ?src/target/firmware/include/layer1/sched_gsmtime.h | ? ?5 ++++-
> > > ?2 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > > -};
> > > +} __packed;
> > 
> > I'm not conviced by this one : Why should we use packed for structures
> > not used as 'communication packets' ?
> > 
> What are the drawbacks ?

normally, the compiler will lay out the structure in a way that
optimizes accesses to members.  So e.g. on an ARM, a 

struct {
	uint8_t byte1;
	uint8_t byte2;
};

will very likely contain 3 bytes padding between the two uint8 values in
order to make sure no unaligned loads/stores will be required.

However, if you change that to '__packed', the padding will not be
generated and any access to struct members will need to deal with
unaligned accesses, which can be inflating the code size considerably.

> Steve and Holger raised some reasonable concerns on some of the other
> patches, it seems I was quite unconcentrated and they are mostly crap.

don't say that.  We love to receive cleanup patches like yours, and
even if 2-3 have some issues, at a series of 8 it is still considerable
gain for the project.

> The patches do not contain any "magic" anyway. Just straight-forward
> reaction on the different kind of warnings. Most of them can be
> eliminated easily.

yes, in most cases.  However, sometimes we keep the warning around as a
reminder that something still needs to be done, such as e.g. handling an
undhandled enum value in switch() or the like.  In such a case of course
we shuold implement the missing member, and not introduce a default
case.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From alexander.huemer at xx.vu  Thu Nov 24 10:51:04 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Thu, 24 Nov 2011 11:51:04 +0100
Subject: [PATCH 8/8] firmware: mark some structs as packed
In-Reply-To: <20111124103309.GC23833@prithivi.gnumonks.org>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-9-git-send-email-alexander.huemer@xx.vu>
	<CAHL+j0-DfG78GSdwRomvXSbm66o_GttAOiKfq478QZfOEEt0cQ@mail.gmail.com>
	<20111124093627.GC21889@de.xx.vu>
	<20111124103309.GC23833@prithivi.gnumonks.org>
Message-ID: <20111124105103.GE21889@de.xx.vu>

On Thu, Nov 24, 2011 at 11:33:09AM +0100, Harald Welte wrote:
> normally, the compiler will lay out the structure in a way that
> optimizes accesses to members.  So e.g. on an ARM, a 
> 
> struct {
> 	uint8_t byte1;
> 	uint8_t byte2;
> };
> 
> will very likely contain 3 bytes padding between the two uint8 values in
> order to make sure no unaligned loads/stores will be required.
> 
> However, if you change that to '__packed', the padding will not be
> generated and any access to struct members will need to deal with
> unaligned accesses, which can be inflating the code size considerably.
thanks for pointing that out. It's actually obvious after a moment of
thinking.

One additional thought on the switch/enum situation and initialisation:
what about adding an additional member to the enum, let's say VOID and
instances of the enum are initialised to that. A switch statement that
handles this enum gets a case for VOID which produces a runtime warning,
much like a default case. this way the compiler is happy, because the
variable is  initialised and also tells you when enum values are not
handled.



From kheimerl at cs.berkeley.edu  Thu Nov 24 03:18:05 2011
From: kheimerl at cs.berkeley.edu (Kurtis Heimerl)
Date: Wed, 23 Nov 2011 19:18:05 -0800
Subject: OsmocomBB Bootstrapping
Message-ID: <CACyT-3nQpZ1O3X6g1QCVmO2QfF2wTEob8BoSX2OSMDZ1LaBJKA@mail.gmail.com>

Hello baseband-devel at lists.osmocom.org!

I've just started my first OsmocomBB project, using a Motorola V171
and the source code in the main git repository. The short hand version
of the story is that we're looking into modifying the GSM MS stack to
allow for the BTS to save some power. This is research being done at
the University of California, and we're sorta amazed at how wonderful
OsmocomBB is for this particular project. Thanks for the work!

Progress has generally been good, and I've been able to build and run
the "hello world" e99 application. Following that, I've moved onto the
mobile app... and run into an issue that I can't seem to resolve by
searching your mailing lists. Basically, each individual process runs
fine:

osmocon installs the compal_e99/layer1.compalram.bin image onto a c155 device
mobile connects (though it doesn't see the SIM for some reason...)
and the terminal is available and active. I'm not able to do much
though, as the MS isn't on yet.

Upon turning the MS on, it scans for a while, eventually detecting my
own cell tower. Terminal is active during this search.

Unfortunately, shortly after detecting and syncing with my tower
(ARFCN 51), the terminal freezes. osmocon begins repeating the
following error:
"Failed to write msg to the socket.."
and nothing else moves. Kaput. Terminal does not respond to any
messages sent. This is my problem, as I'd like to make a call.

PRE-POWERUP
mobile: http://pastebin.com/tPm9ux83

POST-POWERUP
mobile: http://pastebin.com/fMD1Kth6
osmocon: http://pastebin.com/nc3QGGgD
terminal says:
kheimerl at darth-maul /tmp $ telnet localhost 4247
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Welcome to the OsmocomBB control interface
OsmocomBB>
% (MS 1)
% No service.

My intuition is that I've missed setting some key variables in the
related configuration files (~/.osmocom/osmocom.cfg,
~/.osmocom/bb/mobile.cfg). though I can't find ANY documentation about
what's supposed to be in those things.

Any and all help would be appreciated.



From 246tnt at gmail.com  Thu Nov 24 06:52:48 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 24 Nov 2011 07:52:48 +0100
Subject: OsmocomBB Bootstrapping
In-Reply-To: <CACyT-3nQpZ1O3X6g1QCVmO2QfF2wTEob8BoSX2OSMDZ1LaBJKA@mail.gmail.com>
References: <CACyT-3nQpZ1O3X6g1QCVmO2QfF2wTEob8BoSX2OSMDZ1LaBJKA@mail.gmail.com>
Message-ID: <CAHL+j08wiC9feHR8Kb9gh+ari7UPavL5+FCJrFEfoAbkj1hjdw@mail.gmail.com>

> Unfortunately, shortly after detecting and syncing with my tower
> (ARFCN 51), the terminal freezes. osmocon begins repeating the
> following error:
> "Failed to write msg to the socket.."
> and nothing else moves. Kaput. Terminal does not respond to any
> messages sent. This is my problem, as I'd like to make a call.

You're not using the latest code ... this is a bug that was fixed a
couple weeks ago.

Cheers,

    Sylvain



From kheimerl at cs.berkeley.edu  Fri Nov 25 23:38:16 2011
From: kheimerl at cs.berkeley.edu (Kurtis Heimerl)
Date: Fri, 25 Nov 2011 15:38:16 -0800
Subject: OsmocomBB Bootstrapping
In-Reply-To: <CAHL+j08wiC9feHR8Kb9gh+ari7UPavL5+FCJrFEfoAbkj1hjdw@mail.gmail.com>
References: <CACyT-3nQpZ1O3X6g1QCVmO2QfF2wTEob8BoSX2OSMDZ1LaBJKA@mail.gmail.com>
	<CAHL+j08wiC9feHR8Kb9gh+ari7UPavL5+FCJrFEfoAbkj1hjdw@mail.gmail.com>
Message-ID: <CACyT-3mdZBKf8UMKtg3r3Q3o7M5h+i=_b4vLURqvdM5wUis_0w@mail.gmail.com>

This was indeed the problem! Thanks Sylvain.

On Wed, Nov 23, 2011 at 10:52 PM, Sylvain Munaut <246tnt at gmail.com> wrote:
>> Unfortunately, shortly after detecting and syncing with my tower
>> (ARFCN 51), the terminal freezes. osmocon begins repeating the
>> following error:
>> "Failed to write msg to the socket.."
>> and nothing else moves. Kaput. Terminal does not respond to any
>> messages sent. This is my problem, as I'd like to make a call.
>
> You're not using the latest code ... this is a bug that was fixed a
> couple weeks ago.
>
> Cheers,
>
> ? ?Sylvain
>



From holger at freyther.de  Sat Nov 26 08:22:08 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sat, 26 Nov 2011 09:22:08 +0100
Subject: OsmocomBB Bootstrapping
In-Reply-To: <CACyT-3nQpZ1O3X6g1QCVmO2QfF2wTEob8BoSX2OSMDZ1LaBJKA@mail.gmail.com>
References: <CACyT-3nQpZ1O3X6g1QCVmO2QfF2wTEob8BoSX2OSMDZ1LaBJKA@mail.gmail.com>
Message-ID: <4ED0A1B0.3050306@freyther.de>

On 11/24/2011 04:18 AM, Kurtis Heimerl wrote:
> Hello baseband-devel at lists.osmocom.org!
> 
> This is research being done at
> the University of California, and we're sorta amazed at how wonderful
> OsmocomBB is for this particular project. Thanks for the work!

Hi,

I assume you are the same Kurtis as of the "Village Base Station" publication?

cheers
	holger



From alexander.chemeris at gmail.com  Sat Nov 26 09:20:03 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 26 Nov 2011 12:20:03 +0300
Subject: OsmocomBB Bootstrapping
In-Reply-To: <4ED0A1B0.3050306@freyther.de>
References: <CACyT-3nQpZ1O3X6g1QCVmO2QfF2wTEob8BoSX2OSMDZ1LaBJKA@mail.gmail.com>
	<4ED0A1B0.3050306@freyther.de>
Message-ID: <CABmJbFVaoGYSayQ7QMD11QXi6Tirjn3Y=anpzMyRYtHqOL8+wQ@mail.gmail.com>

On Sat, Nov 26, 2011 at 12:22, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> On 11/24/2011 04:18 AM, Kurtis Heimerl wrote:
>> Hello baseband-devel at lists.osmocom.org!
>>
>> This is research being done at
>> the University of California, and we're sorta amazed at how wonderful
>> OsmocomBB is for this particular project. Thanks for the work!
>
> Hi,
>
> I assume you are the same Kurtis as of the "Village Base Station" publication?

He is :)

-- 
Regards,
Alexander Chemeris.



From laforge at gnumonks.org  Fri Nov 25 08:15:20 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 25 Nov 2011 09:15:20 +0100
Subject: RFC: Osmocom developer workshop 2012
Message-ID: <20111125081520.GL1730@prithivi.gnumonks.org>

<DISCLAIMER> Please follow-up to openbsc at lists.osmocom.org </DISCLAIMER>

Hi all,

this idea has been around for quite some time, and for 2012 I really
want to turn it into reality:

	I'd like to have a Osmocom developer workshop

The idea here is to get all the active contributors of the project
together for a couple of days (maybe 2-4 days), in order to exchange
ideas, get to know each other better and last but not least work
together on ironing out some of the more difficult issues.

* City:

Regarding the location:  I think for me it is only possible to organize
it if it is to be held in Berlin.  I'mn happy if somebody else wants to
host it at some other location, but then that person would also have to
take care of local organization.  Berlin also has good train and flight
connections, which is definitely a plus.

* Venue:

If it is in Berlin, we might consider talking with c-base or
Raumfahrtagentur as possible venues.

* Date:

Regarding a proposed date, I'm completely open for suggestions.  Of
course there shouldn't be any overlap with other major FOSS or Sescurity
related conferences, and it should also not coincide with major public
holidays, as that only makes travel + accomodation more expensive.

* Funding:

As we don't have that many commercial users of Osmocom projects, getting
funding for e.g. travel / accomodation is probably going to be
difficult.  We can ask the "usual suspects" among those commercial users
we know,, but I guess it will only be possible in exceptional cases to
provide that kind of funding.

Any ideas / comments / feedback is much appreciated.  If somebody has
a particular suggestion.

<DISCLAIMER> Please follow-up to openbsc at lists.osmocom.org </DISCLAIMER>

Cheers,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           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  Sat Nov 26 00:40:08 2011
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Sat, 26 Nov 2011 01:40:08 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
Message-ID: <20111126004008.GA21629@1984>

On Fri, Nov 25, 2011 at 09:15:20AM +0100, Harald Welte wrote:
> * City:
> 
> Regarding the location:  I think for me it is only possible to organize
> it if it is to be held in Berlin.  I'mn happy if somebody else wants to
> host it at some other location, but then that person would also have to
> take care of local organization.  Berlin also has good train and flight
> connections, which is definitely a plus.

I'm happy with Berlin :-). I can propose Sevilla as alternative, it
can be for the next workshop of course.

But if you want to make it here, it has to be after february 2012.



From dario.lombardo at libero.it  Fri Nov 25 10:30:18 2011
From: dario.lombardo at libero.it (Dario Lombardo)
Date: Fri, 25 Nov 2011 11:30:18 +0100
Subject: Bug in gprs decode software
Message-ID: <CAOYJJfvx6Tynr1z23bGsZ=ojJ0yGw6kGnhny9yfjFSGLmCx5fQ@mail.gmail.com>

Hi guys
Today I'm experiencing a bug in the gprs decode software. In rlcmac.c:190,
when li_off and f->len get invalid values, we have a buffer overflow in the
mempy(). In my case f->len=15, li_off=135.
The really stupid patch to avoid it is below: simply jumps the case. I'm
not able to investigate why li_off becames greater than f->len, causing the
crash. Maybe a check should added.
Have some other seen this crash?

diff --git a/rlcmac.c b/rlcmac.c
index eea02ce..d76a8d6 100644
--- a/rlcmac.c
+++ b/rlcmac.c
@@ -187,11 +187,14 @@ void process_blocks(struct gprs_tbf *t, int ul)
                                        print_pkt(llc_data, llc_len);
                                        fflush(stdout);
                                }
-                               memcpy(llc_data, &f->data[li_off],
f->len-li_off);
-                               llc_len = f->len - li_off;
-                               llc_first_bsn = bsn;
-                               llc_last_bsn = bsn;
-                               t->start_bsn = bsn;
+
+                               if (f->len > li_off && f->len-li_off >
65536) {
+                                   memcpy(llc_data, &f->data[li_off],
f->len-li_off);
+                                   llc_len = f->len - li_off;
+                                   llc_first_bsn = bsn;
+                                   llc_last_bsn = bsn;
+                                   t->start_bsn = bsn;
+                               }
                        }

                }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111125/7888bb90/attachment.htm>

From dario.lombardo at libero.it  Fri Nov 25 10:55:24 2011
From: dario.lombardo at libero.it (Dario Lombardo)
Date: Fri, 25 Nov 2011 11:55:24 +0100
Subject: Bug in gprs decode software
In-Reply-To: <CAOYJJfvx6Tynr1z23bGsZ=ojJ0yGw6kGnhny9yfjFSGLmCx5fQ@mail.gmail.com>
References: <CAOYJJfvx6Tynr1z23bGsZ=ojJ0yGw6kGnhny9yfjFSGLmCx5fQ@mail.gmail.com>
Message-ID: <CAOYJJftg1x1f+5wLB+2knce=KVN+91uJNwuYbnbZ_x8yYeNYYg@mail.gmail.com>

Opps... typo...

-if (f->len > li_off && f->len-li_off > 65536) {
+if (f->len > li_off && f->len-li_off < 65536) {

On Fri, Nov 25, 2011 at 11:30 AM, Dario Lombardo
<dario.lombardo at libero.it>wrote:

> Hi guys
> Today I'm experiencing a bug in the gprs decode software. In rlcmac.c:190,
> when li_off and f->len get invalid values, we have a buffer overflow in the
> mempy(). In my case f->len=15, li_off=135.
> The really stupid patch to avoid it is below: simply jumps the case. I'm
> not able to investigate why li_off becames greater than f->len, causing the
> crash. Maybe a check should added.
> Have some other seen this crash?
>
> diff --git a/rlcmac.c b/rlcmac.c
> index eea02ce..d76a8d6 100644
> --- a/rlcmac.c
> +++ b/rlcmac.c
> @@ -187,11 +187,14 @@ void process_blocks(struct gprs_tbf *t, int ul)
>                                         print_pkt(llc_data, llc_len);
>                                         fflush(stdout);
>                                 }
> -                               memcpy(llc_data, &f->data[li_off],
> f->len-li_off);
> -                               llc_len = f->len - li_off;
> -                               llc_first_bsn = bsn;
> -                               llc_last_bsn = bsn;
> -                               t->start_bsn = bsn;
> +
> +                               if (f->len > li_off && f->len-li_off >
> 65536) {
> +                                   memcpy(llc_data, &f->data[li_off],
> f->len-li_off);
> +                                   llc_len = f->len - li_off;
> +                                   llc_first_bsn = bsn;
> +                                   llc_last_bsn = bsn;
> +                                   t->start_bsn = bsn;
> +                               }
>                         }
>
>                 }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111125/95a4bd5a/attachment.htm>

From martin at hinner.info  Sat Nov 26 01:03:50 2011
From: martin at hinner.info (Martin Hinner)
Date: Sat, 26 Nov 2011 02:03:50 +0100
Subject: MTK and Infineon-based phones
Message-ID: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>

Hi,

  I spent a few hours today looking at CCC presentations and osmocom
code. Good and interesting work! I have a couple of questions...

  This is my first experience with GSM phones reverse engineering, so
sorry if I am wrong, but it seems to be quite difficult for me to
obtain four Calypso-based phones (yes, I know I can order them from
webshop for a few euros, but I will need more of them if my
experiments are successfull). On the other hand, I have access to very
cheap phones using Infineon PMB7880 (C166 + DSP) or MTK (ARM9)
chipsets.

Currently, I do have some information (datasheet&code) for MTK
platform, and I see there is implementation of "secondary bootloader"
for these phones, but no layer1 yet.

I also have very basic documentation of Infineon SoC, plus I have
knowledge of the C166 code and I can very easily play with it (reverse
engineer firmware & assemble my own code).

Is it feasible to create layer1 implementation for Infineon and/or
MTK? Is there anyone willing to help with this?

Here are my additional questions related to the above question:

- Is there any documentation of mask-rom bootloader for Infineon C166 core?

- At this moment I do not understand how does the DSP on the PMB7880
work, if RF part is accessible from both DSP and C166 or just the DSP.

- How is it with Infineon DSP code, is it present in flash memory, or
is it ROM-only thing? Anyone has the code dump?

- Is anyone (who has experience with Calypso layer1) willing to help
with implementing the same on Infineon or MTK platform?

- If anyone has any resources for these two plaforms, I would be
grateful if you can send them to me.

I will add that I have spent many many nights disassembling car
control units using Infineon/Siemens C166 core (since 2002?), so
Infineon platform is very attractive for me (the flash is only 2MB for
some phones, it's easy to read code, etc...).

Thanks,

Martin



From laforge at gnumonks.org  Sat Nov 26 07:23:49 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 26 Nov 2011 08:23:49 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
Message-ID: <20111126072349.GC3773@prithivi.gnumonks.org>

Hi Martin,

On Sat, Nov 26, 2011 at 02:03:50AM +0100, Martin Hinner wrote:
>   This is my first experience with GSM phones reverse engineering, so
> sorry if I am wrong, but it seems to be quite difficult for me to
> obtain four Calypso-based phones (yes, I know I can order them from
> webshop for a few euros, but I will need more of them if my
> experiments are successfull). 
>
> Currently, I do have some information (datasheet&code) for MTK
> platform, and I see there is implementation of "secondary bootloader"
> for these phones, but no layer1 yet.

the question really is how many of them you need.

> On the other hand, I have access to very cheap phones using Infineon
> PMB7880 (C166 + DSP) or MTK (ARM9) chipsets.

Economically, the question is:
* what is the price of the required qty of calypso based phones
	vs
* what is the amount of work needed for porting to MTK

Even under the most ideal circumstances, porting the L1 to any new
baseband chip architecture is going to be a lot of work.  

As "ideal circumstances" I count
 * detailed knowledge about not only the integrated peripherals of the
   DBB but also register-level documentation of the ABB
 * detailed knowledge about the shared memory API between DSP-ROM and
   ARM CPU
 * no cryptographic verification in bootloader that needs to be broken
 * a developer who has very strong background on GSM L1 and cellphone
   hardware
 * access to measurement devices for MS testing like Racal 6103

Even under such circumstances, I would guess an effort of somewhere
between 1 to 2 man-months full-time.

As the circumstances are never ideal, it will likely be more effort.

Some developers have already put quite a bit of effort into the MTK
chipset side, and even though we don't have the register-level data
sheets of all of the ABB chips and the DBB data sheets do not cover
anything on the details of the DSP/ARM API interface, I think it is the
most promising architecture.

> Is it feasible to create layer1 implementation for Infineon and/or
> MTK? Is there anyone willing to help with this?

I think the big issue is availability.  The people invovled in OsmocomBB
are working on a variety of other projects and protocol stacks
(OsmocomGMR, OsmocomTETRA, osmo-bts, etc.)

So the big question is: How can you convince anyone from the existing
team to contribute to a port to MTK?  I think the fact that the code
runs well on the Calypso based phones (which are still avialable even in
quantity) makes this a bit difficult, as there is no real gain.

People generally want to work on creating new functionality, rather than
re-creating something that already exists...

> I will add that I have spent many many nights disassembling car
> control units using Infineon/Siemens C166 core (since 2002?), so
> Infineon platform is very attractive for me (the flash is only 2MB for
> some phones, it's easy to read code, etc...).

On the other hand: C166 is a one-way road.  No new baseband chipsets
(even infineon) use them anymore.  You need to port all the arm-specific
assembly bits in OsmocomBB  to the C166 code, etc.

MTK is a much more attractive target. More docs, more understanding,
more existing code and ARM based.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From martin at hinner.info  Sat Nov 26 13:25:19 2011
From: martin at hinner.info (Martin Hinner)
Date: Sat, 26 Nov 2011 14:25:19 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <20111126072349.GC3773@prithivi.gnumonks.org>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
Message-ID: <CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>

Harald,

On Sat, Nov 26, 2011 at 8:23 AM, Harald Welte <laforge at gnumonks.org> wrote:
> Economically, the question is:
> * what is the price of the required qty of calypso based phones
> ? ? ? ?vs
> * what is the amount of work needed for porting to MTK

yes, you are right. One more thing is in my mind, will China produce
enough Calypso-based phones forever? I found 10 MTK-based phones on
the market, but not even one TI-based.The problem is that I cannot
make any assumptions about amount of work needed to do the l1 task,
that's why I asked on the list.

[ One more thing, what about making a page on Wiki that lists various
phone models with used chips? I can add what I have found so far. ]

> Some developers have already put quite a bit of effort into the MTK
> chipset side, and even though we don't have the register-level data
> sheets of all of the ABB chips and the DBB data sheets do not cover
> anything on the details of the DSP/ARM API interface, I think it is the
> most promising architecture.

Can you point me right direction? I have found some MTK code in git,
but there is no documentation at all, etc.

Martin



From wolfram at the-dreams.de  Sat Nov 26 17:15:03 2011
From: wolfram at the-dreams.de (Wolfram Sang)
Date: Sat, 26 Nov 2011 18:15:03 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
Message-ID: <4ED11E97.2070306@the-dreams.de>

> Can you point me right direction? I have found some MTK code in git,
> but there is no documentation at all, etc.

Osmocom hosts a git-repo for u-boot and kernel. Both reflect the
status-quo as far as I know. Same for the wiki-pages on osmocom-bb about
Sciphone G2, they should be the status quo. Specs float around the net;
the list archive might have some pointers. (Hey, Marcin, where are the
barebox-patches BTW ;))

Regards,

   Wolfram



From martin at hinner.info  Sat Nov 26 17:52:39 2011
From: martin at hinner.info (Martin Hinner)
Date: Sat, 26 Nov 2011 18:52:39 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <4ED11E97.2070306@the-dreams.de>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
Message-ID: <CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>

Hi,

On Sat, Nov 26, 2011 at 6:15 PM, Wolfram Sang <wolfram at the-dreams.de> wrote:
> Osmocom hosts a git-repo for u-boot and kernel. Both reflect the
> status-quo as far as I know. Same for the wiki-pages on osmocom-bb about
> Sciphone G2, they should be the status quo. Specs float around the net;

I meant l1-related code, some parts - for example
http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mt62xx
 or http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mediatek
...

The kernel for MTK does not seem to have any signs of gsm layer 1 code.

Sorry for confusion...

Martin



From steve at steve-m.de  Sat Nov 26 18:04:57 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Sat, 26 Nov 2011 19:04:57 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
Message-ID: <4ED12A49.9010107@steve-m.de>

Hi,

On 26.11.2011 18:52, Martin Hinner wrote:
> I meant l1-related code, some parts - for example

Marcin has implemented some L1 functionality to U-Boot, see his mail
back in march:

http://lists.osmocom.org/pipermail/baseband-devel/2011-March/001554.html

The corresponding commit to uboot-mt623x.git:

http://cgit.osmocom.org/cgit/uboot-mt623x/commit/?id=18aa4c659a3e4b1b6262a0f617598674055f4d06

Regards,
Steve



From wolfram at the-dreams.de  Sat Nov 26 18:15:05 2011
From: wolfram at the-dreams.de (Wolfram Sang)
Date: Sat, 26 Nov 2011 19:15:05 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <4ED12A49.9010107@steve-m.de>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
	<4ED12A49.9010107@steve-m.de>
Message-ID: <4ED12CA9.90304@the-dreams.de>

> Marcin has implemented some L1 functionality to U-Boot, see his mail
> back in march:

Ups, right, I forgot about this. We mainly talked about the DSP the last
time :)



From wolfram at the-dreams.de  Sat Nov 26 18:09:45 2011
From: wolfram at the-dreams.de (Wolfram Sang)
Date: Sat, 26 Nov 2011 19:09:45 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>	<20111126072349.GC3773@prithivi.gnumonks.org>	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
Message-ID: <4ED12B69.9010408@the-dreams.de>

> I meant l1-related code, some parts - for example
> http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mt62xx
>  or http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mediatek

This is only used for the loader code, so you can get a bootloader into
the phone without JTAG and using osmocon. In other words, UART support only.

> The kernel for MTK does not seem to have any signs of gsm layer 1 code.

All known info is here: http://bb.osmocom.org/trac/wiki/MT6235_DSP
Once more is known, layer1 could be implemented.

Regards,

   Wolfram



From laforge at gnumonks.org  Sat Nov 26 18:18:06 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 26 Nov 2011 19:18:06 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
Message-ID: <20111126181806.GJ3773@prithivi.gnumonks.org>

Hi Martin,

On Sat, Nov 26, 2011 at 06:52:39PM +0100, Martin Hinner wrote:

> I meant l1-related code, some parts - for example
> http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mt62xx
>  or http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mediatek
> ...
> 
> The kernel for MTK does not seem to have any signs of gsm layer 1 code.

please check the list archives
http://lists.osmocom.org/pipermail/baseband-devel/2011-March/001554.html

and the code in u-boot which the abovementioned link talks about:
http://cgit.osmocom.org/cgit/uboot-mt623x/commit/?id=18aa4c659a3e4b1b6262a0f617598674055f4d06

This is the furthest that has been done on MTK, as far as we know.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From marcin.mielczarczyk at gmail.com  Sun Nov 27 00:17:37 2011
From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk)
Date: Sun, 27 Nov 2011 01:17:37 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <20111126181806.GJ3773@prithivi.gnumonks.org>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
	<20111126181806.GJ3773@prithivi.gnumonks.org>
Message-ID: <CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>

Hi Martin,

> On the other hand, I have access to very cheap phones using Infineon
> PMB7880 (C166 + DSP) or MTK (ARM9) chipsets.

Note, that on the market there is much more Mediatek phones based on ARM7
(MT622x) than on ARM9 (MT623x).
I mainly focused on MT623x series of Mediatek SoC, which is based on
ARM926EJ-S with MMU support.
My Linux port for this architecture didn't touch L1 at all. I focused first
on getting "application" cpu up and running.
This went quite well and then I tried to understand how L1 works.
Writing driver for MT6140 helped me understand basics of baseband part of
the phone.
I managed to configure TX path to transfer data on given frequency and
after that I had to have DSP running to send "proper" data.
I got stack on DSP part, because I tried first to download firmware from
DSP ROM. This didn't work out so far.
Better approach would be to disassemble and understand DSP-ARM API and use
it as it is, without firmware changing for now.
Unfortunately I couldn't find time to work on that due to my professional
work.
Anyway, all the links are already given in this thread and that's the
current status. I described all my findings on OsmocomBB wiki.

@Wolfram: I'll probably submit barebox port with update of Mediatek kernel
code to 3.2 kernel version.

BR,
Marcin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111127/61ef1bc3/attachment.htm>

From martin at hinner.info  Sun Nov 27 04:44:08 2011
From: martin at hinner.info (Martin Hinner)
Date: Sun, 27 Nov 2011 05:44:08 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CAPVwjkxmtKQ3=osvoOsx3O_nqDDjwXubVfFTxUpOA+Ju22dUNQ@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
	<20111126181806.GJ3773@prithivi.gnumonks.org>
	<CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>
	<CAPVwjkxmtKQ3=osvoOsx3O_nqDDjwXubVfFTxUpOA+Ju22dUNQ@mail.gmail.com>
Message-ID: <CAPVwjkz4-DrD0opT10ZCNpHy=R3mjgPEsmxcNpVDo0-7YCj-cA@mail.gmail.com>

Hi Marcin,

On Sun, Nov 27, 2011 at 1:17 AM, Marcin Mielczarczyk
<marcin.mielczarczyk at gmail.com> wrote:
> Note, that on the market there is much more Mediatek phones based on ARM7
> (MT622x) than on ARM9 (MT623x).

You are right, it makes sense. My mistake. I was only working with
flash dumps so far...

I have spent some time analyzing mtk-phone project. There is a lot of
files missing, but the situation is not so bad. My feeling is that
some of the files were simply deleted from the project... (interrupted
upload?)

I made a list of all files needed to link binary image (from .lis file).
Then I did: find . -name '*.c'
Then I ran ar l on al mtk-lib .lib files (these can be quite easily
disassembled).
And finally diff helped to find what is missing...


We're missing only these files (no .obj in .lib or .c is present in
the project):

-lic.c
-drvflash.c
-l1c_trace.c
-l1d2_trace.c
-l1d3_trace.c
-l1d_edge_trace.c
-l1d_trace.c
-l1sc_trace.c
-l1trc.c
-l4drv.c
-sst_decrypt.c
-sst_intrctrl.c
-sst_secure.c
-trcmod.c

I think none of these are needed for our stuff.

Then we are missing .c files, but have .obj in .lib (only important files)

dp_engine.lib: awb_bitstream.c (unknown for what is this)

dsp_ram.lib: ddload.c
dsp_ram.lib: dsp_ptch_6223.c (we can get this from binary)
dsp_ram.lib: idma.c

l1.lib: l1csm.c
l1.lib: l1dsm.c
l1.lib: m*.c (it's a lot of files !!!!!!!!!!!!)

In fact this is end of all important routines...

Tracing functions:
l1.lib: l1i_amr_trace.c
l1.lib: l1i_cs_trace.c
l1.lib: l1sc_trace.c
l1.lib: l1t_amr_trace.c
l1.lib: l1c3_trace.c
l1.lib: l1c4_trace.c
l1.lib: l1c_csd_trace.c
l1.lib: l1c_trace.c
l1.lib: l1d2_trace.c
l1.lib: l1d3_trace.c
l1.lib: l1d_edge_trace.c
l1.lib: l1d_trace.c

l1.lib: rftool_gsm.c (shows how to call various functions)

Only for testing:
l1.lib: l1tst_afc.c
l1.lib: l1tst_agc.c
l1.lib: l1tst_cfg.c
l1.lib: l1tst_cont.c
l1.lib: l1tst_fcb.c
l1.lib: l1tst_fhc.c
l1.lib: l1tst_nbtx.c
l1.lib: l1tst_pm.c
l1.lib: l1tst_ul.c

I have already tried to disassemble some of them and it all makes
sense, most of functions are very simple and some files are not even
needed. My feeling is that we have all needed to understand the DSP
functionality / L1 part of the ARM code! The biggest problem is that
m*.c files depend on hardware (a lot of #ifdefs), so this needs to be
analyzed on firmware downloaded from hardware. [ Question: why such
cryptic names such as m12170.c ? ]

I also have list of functions in those files, if anyone's interested
in helping me with locating what is important and what is not... (34
kB).

Martin



From marcin.mielczarczyk at tieto.com  Mon Nov 28 08:15:25 2011
From: marcin.mielczarczyk at tieto.com (Mielczarczyk Marcin)
Date: Mon, 28 Nov 2011 09:15:25 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CAPVwjkz4-DrD0opT10ZCNpHy=R3mjgPEsmxcNpVDo0-7YCj-cA@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>	<20111126072349.GC3773@prithivi.gnumonks.org>	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>	<4ED11E97.2070306@the-dreams.de>	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>	<20111126181806.GJ3773@prithivi.gnumonks.org>	<CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>	<CAPVwjkxmtKQ3=osvoOsx3O_nqDDjwXubVfFTxUpOA+Ju22dUNQ@mail.gmail.com>
	<CAPVwjkz4-DrD0opT10ZCNpHy=R3mjgPEsmxcNpVDo0-7YCj-cA@mail.gmail.com>
Message-ID: <4ED3431D.7080009@tieto.com>

Hi Martin,

On 11/27/2011 05:44 AM, Martin Hinner wrote:
> I have spent some time analyzing mtk-phone project. There is a lot of
> files missing, but the situation is not so bad. My feeling is that
> some of the files were simply deleted from the project... (interrupted
> upload?)

Files are deleted by purpose. This code is probably uploaded by customer 
of Mediatek platform (some phone producer), and they don't get source 
code for all of the parts. Most probably even in Mediatek company L1 and 
DSP code is shared as libraries and only people working on development 
of these parts have access to source code.

> I think none of these are needed for our stuff.

I agree.

> dsp_ram.lib: ddload.c
> dsp_ram.lib: dsp_ptch_6223.c (we can get this from binary)
> dsp_ram.lib: idma.c
>

These files are responsible for uploading of DSP patches and are crucial 
to understand upload process. I tried with Krzysztof Antonowicz to 
upload some DSP code and try execute it using routines from these files 
but no successes at all. I described some of them on the wiki as you 
probably saw.

> l1.lib: m*.c (it's a lot of files !!!!!!!!!!!!)

These m*.c are important and I remember that I tried to find source code 
for them. I don't remember right now what was implemented there, but 
I'll take a look on it and refresh my memory.

> I have already tried to disassemble some of them and it all makes
> sense, most of functions are very simple and some files are not even
> needed. My feeling is that we have all needed to understand the DSP
> functionality / L1 part of the ARM code! The biggest problem is that
> m*.c files depend on hardware (a lot of #ifdefs), so this needs to be
> analyzed on firmware downloaded from hardware. [ Question: why such
> cryptic names such as m12170.c ? ]

I was disassembling code on running target using JTAG which is much 
easier than static analysis. As I written before, I focused so much on 
getting execution of my code on DSP, that when it didn't work I gave up. 
But it's not the way to go. As you have written, libraries are pretty 
readable and we're able to understand how to use DSP with existing code. 
I'm willing to get back to this work, so I can help you with that.

BR,
Marcin



From martin at hinner.info  Mon Nov 28 13:33:01 2011
From: martin at hinner.info (Martin Hinner)
Date: Mon, 28 Nov 2011 14:33:01 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <4ED3431D.7080009@tieto.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
	<20111126181806.GJ3773@prithivi.gnumonks.org>
	<CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>
	<CAPVwjkxmtKQ3=osvoOsx3O_nqDDjwXubVfFTxUpOA+Ju22dUNQ@mail.gmail.com>
	<CAPVwjkz4-DrD0opT10ZCNpHy=R3mjgPEsmxcNpVDo0-7YCj-cA@mail.gmail.com>
	<4ED3431D.7080009@tieto.com>
Message-ID: <CAPVwjkypA3WoHKLgCL1TjWqf7CSbWGGFg2AOg6LVFqZoMcciGw@mail.gmail.com>

On Mon, Nov 28, 2011 at 9:15 AM, Mielczarczyk Marcin
<marcin.mielczarczyk at tieto.com> wrote:
> Files are deleted by purpose. This code is probably uploaded by customer of
> Mediatek platform (some phone producer), and they don't get source code for
> all of the parts. Most probably even in Mediatek company L1 and DSP code is
> shared as libraries and only people working on development of these parts
> have access to source code.

There are some files missing so you cannot even link the project into
binary... but I agree that some missing files are due to lib-only
distribution of the platform files.

> These files are responsible for uploading of DSP patches and are crucial to
> understand upload process. I tried with Krzysztof Antonowicz to upload some
> DSP code and try execute it using routines from these files but no successes
> at all. I described some of them on the wiki as you probably saw.

I know, I have already disassembled all of this and it all makes sense.

> than static analysis. As I written before, I focused so much on getting
> execution of my code on DSP, that when it didn't work I gave up. But it's
> not the way to go. As you have written, libraries are pretty readable and

Can you share you DSP work with me? You can mail it directly to me so
as we're not posting useless data on the mailing list (at least for
most people).

I have extracted the patching code from binary (it's 8192 bytes long),
there are 2 of them. I do not have any disassembler for AD's DSPs, so
I had to do it manually, but the code did not match any opcodes (the
resulting code did not make any sense).

Martin



From laforge at gnumonks.org  Sun Nov 27 07:13:56 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 27 Nov 2011 08:13:56 +0100
Subject: MTK based phones
In-Reply-To: <CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>
	<20111126072349.GC3773@prithivi.gnumonks.org>
	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>
	<4ED11E97.2070306@the-dreams.de>
	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>
	<20111126181806.GJ3773@prithivi.gnumonks.org>
	<CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>
Message-ID: <20111127071356.GS3773@prithivi.gnumonks.org>

Hi Marcin and Martin,

On Sun, Nov 27, 2011 at 01:17:37AM +0100, Marcin Mielczarczyk wrote:
 
> > On the other hand, I have access to very cheap phones using Infineon
> > PMB7880 (C166 + DSP) or MTK (ARM9) chipsets.
> 
> Note, that on the market there is much more Mediatek phones based on ARM7
> (MT622x) than on ARM9 (MT623x).

ACK.

> My Linux port for this architecture didn't touch L1 at all. I focused first
> on getting "application" cpu up and running.
> I managed to configure TX path to transfer data on given frequency and
> after that I had to have DSP running to send "proper" data.

All of this, once again, quite amazing work you've been pulling off.  I
really regret that nobody (including myself) has ever since picked up on
it :(

> I got stack on DSP part, because I tried first to download firmware from
> DSP ROM. This didn't work out so far.
> Better approach would be to disassemble and understand DSP-ARM API and use
> it as it is, without firmware changing for now.

Indeed, I agree, the best approach (like we took on Calypso) is to try
to use the DSP ROM code as-is.  This reduces the required work to:

1) understand how to bring up (boot/start) the DSP from the ARM
2) understand how to drive the API from the ARM and feed instructions
   into the DSP as well as read results
3) writing the required scheduler around those instruction/result
   primitives, possibly porting/re-using some of the calypso L1 scheduler

> Unfortunately I couldn't find time to work on that due to my professional
> work.

We can all understand that, but it's a real pity...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From marcin.mielczarczyk at tieto.com  Mon Nov 28 08:29:25 2011
From: marcin.mielczarczyk at tieto.com (Mielczarczyk Marcin)
Date: Mon, 28 Nov 2011 09:29:25 +0100
Subject: MTK based phones
In-Reply-To: <20111127071356.GS3773@prithivi.gnumonks.org>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>	<20111126072349.GC3773@prithivi.gnumonks.org>	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>	<4ED11E97.2070306@the-dreams.de>	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>	<20111126181806.GJ3773@prithivi.gnumonks.org>	<CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>
	<20111127071356.GS3773@prithivi.gnumonks.org>
Message-ID: <4ED34665.2070405@tieto.com>

On 11/27/2011 08:13 AM, Harald Welte wrote:
>
> All of this, once again, quite amazing work you've been pulling off.  I
> really regret that nobody (including myself) has ever since picked up on
> it :(

I don't receive it like that. Thanks to this I had motivation to switch 
to baseband part which was always black box for me. I learned probably 
more investigating and implementing than by analyzing code. It's still 
in my ambition to get MTK L1 working together with Linux.
Especially that MT6516 has some parts similar to old family of MT62xx 
and we could have a way forward.

>> Unfortunately I couldn't find time to work on that due to my professional
>> work.
>
> We can all understand that, but it's a real pity...

I'd like to get back to this work and as you see we have new people 
coming so maybe we'll be able to get it rolling again.

BR,
Marcin



From wolfram at the-dreams.de  Sun Nov 27 16:11:20 2011
From: wolfram at the-dreams.de (Wolfram Sang)
Date: Sun, 27 Nov 2011 17:11:20 +0100
Subject: MTK and Infineon-based phones
In-Reply-To: <CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>
References: <CAPVwjky5wS2C17_bssXqUV5oXuY-c1bBdfCjhnS0ytxo3FBSVQ@mail.gmail.com>	<20111126072349.GC3773@prithivi.gnumonks.org>	<CAPVwjkwQArbPg=0kuAYyNAfGoxJPHmnecunuxVAcPmfg=cjRVA@mail.gmail.com>	<4ED11E97.2070306@the-dreams.de>	<CAPVwjkyfRg866d4HduMonfsUQL5Nbru9Ri9Lbyunm-YrEyaMZA@mail.gmail.com>	<20111126181806.GJ3773@prithivi.gnumonks.org>
	<CANitqVu1cTUkFUvKsv8PAw55bMdR=jzbR-tmKFEhkdv8WJfDng@mail.gmail.com>
Message-ID: <4ED26128.4090708@the-dreams.de>

> @Wolfram: I'll probably submit barebox port with update of Mediatek
> kernel code to 3.2 kernel version.

Yay \o/ Let's go mainline :)



From rm.engineer84 at gmail.com  Sat Nov 26 05:59:39 2011
From: rm.engineer84 at gmail.com (R M)
Date: Sat, 26 Nov 2011 11:29:39 +0530
Subject: osmocom-bb cygwin
In-Reply-To: <F9A3C72B89D64EFC9DBA83BD6AC55AB0@Maite>
References: <F9A3C72B89D64EFC9DBA83BD6AC55AB0@Maite>
Message-ID: <CADKJHGaLy31yuCetU_jJ5dsHgs+dnghWDjXbA9Jdwm7f8RjVwg@mail.gmail.com>

Hi,

Its better you send the mail to the list rather than just to me. In
that way you get more help.

I have built osmocom using cygwin. But I am unable to get the code
downloaded into the phone. I am facing timing issues.

I am still looking into the issue though.


The instructions to install cygwin are found at:

http://cygwin.com/.

By default cygwin installs just the basic tools.

Once you have installed the basic tools, you have to run the installer
again to get the tools required for building osmocom.

The tools required are given in the Wiki at this link:

http://bb.osmocom.org/trac/wiki/GettingStarted.

Once you have done that you need to install gnu arm.

In the same wiki you have the links to download the cygwin version of GNU Arm.

The ftdi cable I use is at this link:http://www.sparkfun.com/products/8772.

Regards,
RM




On 11/24/11, Juantxi <juantxipazos at yahoo.es> wrote:
> hello,
> osmocom-bb got compile using cygwin?
> packages could tell me that you downloaded?
> which cable did you use?
>
> I am interested in doing
> thanks
>



From holger at freyther.de  Sat Nov 26 21:19:08 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sat, 26 Nov 2011 22:19:08 +0100
Subject: RFC Wiki re-org of bb.osmocom.org
Message-ID: <4ED157CC.80401@freyther.de>

Hi,

I have recently tried to find some information in our wiki and it was more
difficult than I think it should be. I would like to propose and then
implement some restructuring. So first of all I think we have good enough
content, it is just a matter of structure.

Front Page:
I would like to have a very simple and structured entry. Mainly pointing to
other projects, History, Software and Hardware?



Hardware Pages
Our hardware pages are mostly the same but actually quite different. I would
like to find the following information on each page:
	- Which firmware/board to use (compal_e88)...
	- Picture of assembled/disassembled device
	- Knowledge we have

I would like to move all Hardware/MotorolaCXX. The example would be to have
hardware/ like this[1] and hardware/MotorolaC118 like this[2].


Software Pages:
We have the Getting Started but there appears to be a gap from having a
toolchain (or building one) and knowing how the various parts are connected to
each other. I have not thought about it too much though.


History Pages:
I would move some older information in there. E.g. our never started/finished
Calypso based design, maybe some parts of the project history.

comments? ideas?

	holger

[1] http://wiki.openwrt.org/toh/start#supported.hardware.-.router.type
[2] http://wiki.openwrt.org/toh/buffalo/whr-g125



From peter at stuge.se  Sat Nov 26 22:24:16 2011
From: peter at stuge.se (Peter Stuge)
Date: Sat, 26 Nov 2011 23:24:16 +0100
Subject: RFC Wiki re-org of bb.osmocom.org
In-Reply-To: <4ED157CC.80401@freyther.de>
References: <4ED157CC.80401@freyther.de>
Message-ID: <20111126222416.12529.qmail@stuge.se>

Holger Hans Peter Freyther wrote:
> comments? ideas?

Enthousiastic thumbs up. Go for it.


//Peter



From laforge at gnumonks.org  Sun Nov 27 06:53:00 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 27 Nov 2011 07:53:00 +0100
Subject: RFC Wiki re-org of bb.osmocom.org
In-Reply-To: <4ED157CC.80401@freyther.de>
References: <4ED157CC.80401@freyther.de>
Message-ID: <20111127065300.GP3773@prithivi.gnumonks.org>

On Sat, Nov 26, 2011 at 10:19:08PM +0100, Holger Hans Peter Freyther wrote:
> Hi,
> 
> I have recently tried to find some information in our wiki and it was more
> difficult than I think it should be. I would like to propose and then
> implement some restructuring. So first of all I think we have good enough
> content, it is just a matter of structure.

Go ahead, any structure is better than no structure ;)

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From acassis at gmail.com  Sun Nov 27 13:30:58 2011
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Sun, 27 Nov 2011 11:30:58 -0200
Subject: [PATCH] i2c: fix maximum address an I2C chip can assign
Message-ID: <CAG4Y6eR7rzovoCbW9PVB=THWasAdN3XFvjdBkUwCxTMhZumSYA@mail.gmail.com>

I2C bus support up to 128 devices (mask 0x7F), but current calypso driver
is masked it to 64 (0x3F). I discover it because Motorola W220 has an I/O
expander PCA9537 at address 0x49 which could be reached.

Signed-off-by: Alan Carvalho de Assis <acassis at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-i2c-fix-maximum-address-an-I2C-chip-can-assign.patch
Type: text/x-patch
Size: 1176 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111127/a0c6fd91/attachment.bin>

From steve at steve-m.de  Sun Nov 27 13:38:58 2011
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 27 Nov 2011 14:38:58 +0100
Subject: [PATCH] i2c: fix maximum address an I2C chip can assign
In-Reply-To: <CAG4Y6eR7rzovoCbW9PVB=THWasAdN3XFvjdBkUwCxTMhZumSYA@mail.gmail.com>
References: <CAG4Y6eR7rzovoCbW9PVB=THWasAdN3XFvjdBkUwCxTMhZumSYA@mail.gmail.com>
Message-ID: <4ED23D72.8060209@steve-m.de>

On 27.11.2011 14:30, Alan Carvalho de Assis wrote:
> I2C bus support up to 128 devices (mask 0x7F), but current calypso driver
> is masked it to 64 (0x3F). I discover it because Motorola W220 has an I/O
> expander PCA9537 at address 0x49 which could be reached.
> 
> Signed-off-by: Alan Carvalho de Assis <acassis at gmail.com>

Committed it to master.

Regards,
Steve