From uwe at hermann-uwe.de Sat Apr 17 18:27:56 2010 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 17 Apr 2010 20:27:56 +0200 Subject: large collection of gsm related datasheets In-Reply-To: <866320f71003260901v3e55d104j1bacbbf22a781b3d@mail.gmail.com> References: <4BACD212.6030800@xs4all.nl> <866320f71003260901v3e55d104j1bacbbf22a781b3d@mail.gmail.com> Message-ID: <20100417182756.GA15972@greenwood> On Fri, Mar 26, 2010 at 05:01:32PM +0100, Sylvain Munaut wrote: > > i found this, searching google/codesearch for 'ftm_cmd' > > > > svn co http://hwplatform.googlecode.com/svn/trunk/ > > > > about 1.5G of datasheets, sourcecode, and tools > > for various phones. > > very nice :) Also have a look at these repos: http://code.google.com/u/wenhen/ The code mentioned above seems to be part of a larger collection of phone-related stuff. Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From itsme at xs4all.nl Sun Apr 18 00:33:52 2010 From: itsme at xs4all.nl (itsme) Date: Sun, 18 Apr 2010 02:33:52 +0200 Subject: large collection of gsm related datasheets In-Reply-To: <20100417182756.GA15972@greenwood> References: <4BACD212.6030800@xs4all.nl> <866320f71003260901v3e55d104j1bacbbf22a781b3d@mail.gmail.com> <20100417182756.GA15972@greenwood> Message-ID: Sent from my iPhone > http://code.google.com/u/wenhen/ wow, thanks. i had not looked that far. 10g of docs. Willem From wolfgang at sharism.cc Mon Apr 19 05:11:32 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Mon, 19 Apr 2010 05:11:32 +0000 Subject: large collection of gsm related datasheets In-Reply-To: References: <4BACD212.6030800@xs4all.nl> <866320f71003260901v3e55d104j1bacbbf22a781b3d@mail.gmail.com> <20100417182756.GA15972@greenwood> Message-ID: <20100419051132.GA2096@devel.wolf> Willem, > >http://code.google.com/u/wenhen/ > wow, thanks. i had not looked that far. > 10g of docs. can you check whether there are any schematics of particular phone models using MT6223 or MT6225 in that pile of docs? As Harald pointed out in another mail, what is super easy to find are MTK reference schematics, whereas the schematics for actual MTK-based phone models are harder to come by. Wolfgang From nat at fains.com Mon Apr 5 05:17:38 2010 From: nat at fains.com (Nathan Fain) Date: Sun, 04 Apr 2010 22:17:38 -0700 Subject: noisy cable? In-Reply-To: <4BB08367.7060107@xs4all.nl> References: <4BB08367.7060107@xs4all.nl> Message-ID: <4BB97272.70006@fains.com> fyi, using the /dev/cu.** variant solved my problem of osmocon being unable to write CMD1 to the port. At least, it worked with an FTDI cable I built. I imagine it will solve the issue with the prolific cable as well (will try later). On 29/03/2010 03:39, willem wrote: > i managed to get hello_world working on my c121, connected through a > pl2303 usb/serial cable to my macbookpro. > > but found that the connection is extremely noisy. > often the movement of me putting down the phone on the table is enough > to break the upload. > is that a common problem with these headphone/serial cable plugs? > > > for the serial device i can use /dev/cu.PL2303-0000201A > or /dev/tty.PL2303-0000201A > > but when using the '/dev/tty...' variant, i have to add this to osmocon.c > > diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c > index f934dd7..b361eb1 100644 > --- a/src/host/osmocon/osmocon.c > +++ b/src/host/osmocon/osmocon.c > @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev) > /* hardware flow control off */ > options.c_cflag &= ~CRTSCTS; > > + /* ignore modem status lines */ > + options.c_cflag |= CLOCAL; > + > /* software flow control off */ > options.c_iflag &= ~(IXON | IXOFF | IXANY); > > ============================= > > willem > > > > From Andreas.Eversberg at versatel.de Thu Apr 1 11:44:26 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 1 Apr 2010 13:44:26 +0200 Subject: message handling Message-ID: hi, today i will finally (begin to) structure the message handling in my current work on layer 3: the message handling functions consist of: - message cration - message sending - message en-queueing - message de-queueing i deal with interfaces (SAP): - between application and call control (MNCC-SAP) - between call controll and mobility management (MMCC-SAP) - between supplementary services protocol and mobility management (MMSS-SAP) - between sms protocol and mobility management (MMSMS-SAP) - between mobility management and radio ressource (RR-SAP) - between radio ressource and layer 2 / layer 1 (let's call it RSLms-SAP) additionally there are interfaces: - between application and mobility management - between application and PLMN search - to the sim card - to the application - ... here is what i think the messages should look like. please correct me if i am wrong or if you have suggestions: MNCC-SAP: MMCC-SAP, MMSS-SAP, MMSMS-SAP: [] RR-SAP: [] RSL-SAP: [] * the layer 3 message consists of the gsm48_hdr structure + additional information elements. if a layer 3 message moves from call control down to RSL and even lower, the inter-layer headers are pulled and pushed. additionally there are pointers to the beginning of the headers inside the message: - l1h - l2h - l3h - layer 4 headers - layer 5 header the inter-layer messages (MMxx-SAP and RR-SAP) will have no pointer to the message structures. i think they also should not have them, since they have fixed length and are pushed at the time they are sent, and pulled at the time they are received. any suggestions? andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Apr 5 01:24:45 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 5 Apr 2010 09:24:45 +0800 Subject: Developer Meeting in Berlin / 2010-04-10 Message-ID: <20100405012445.GH9818@prithivi.gnumonks.org> Hi all! Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin. This is mainly for me to get an idea where we are (compared to before my holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog. I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system. I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join! Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Mon Apr 5 15:20:24 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 5 Apr 2010 17:20:24 +0200 Subject: AW: Developer Meeting in Berlin / 2010-04-10 Message-ID: hi harald, i would like to participate (and others maybe too). what if we have somethink like a conference for all the people not in berlin? in our company we do it this way: - a conference number is dialed by all members. - a phone with hands free option can be used on one place where multiple members are. - netmeeting is used for presentation. this can also be via VNC remote desktop. is it possible for you in berlin to establish a VNC server with multiple access, or at least something like a "screen" command? my PRI test machine in my company can be used as conference server for up to 30 parties. it has a german dial-up number. regrads, andreas -----Urspr?ngliche Nachricht----- Von: baseband-devel-bounces at lists.osmocom.org [mailto:baseband-devel-bounces at lists.osmocom.org] Im Auftrag von Harald Welte Gesendet: Montag, 5. April 2010 03:25 An: baseband-devel at lists.osmocom.org Betreff: Developer Meeting in Berlin / 2010-04-10 Hi all! Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin. This is mainly for me to get an idea where we are (compared to before my holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog. I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system. I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join! Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Apr 6 00:04:49 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Apr 2010 08:04:49 +0800 Subject: Developer Meeting in Berlin / 2010-04-10 In-Reply-To: References: Message-ID: <20100406000449.GD25540@prithivi.gnumonks.org> Dear Andreas, see my other mail on this subject that I just sent to Samuel and the list. I really think any of this is unneccessary in such an informal meet-up. What will likely happen is: * prom will give an update on the loader * dexter (if present) might have some questions on how to continue with the sim card reader driver * roh (if present) might mention something about battery charging * i might give a short summarry of the status of layer1 and bcch scanning on which i'm working now. We do have some telephones at the CCCB, but the venue is very noisy as there are other people around. Also, there is no explicit conference phone and we are limited to being calles (as opposed to call out), as we actually don't really have our own phone line. Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From samuel.omlin at gmail.com Mon Apr 5 19:59:37 2010 From: samuel.omlin at gmail.com (Samuel Omlin) Date: Tue, 6 Apr 2010 03:59:37 +0800 Subject: Developer Meeting in Berlin / 2010-04-10 Message-ID: Hi Harald, That's a bright idea for all the developers behind the project as well as those observers around the project to make a brainstorm with the development and evolution of the project. It's a little pity, however, for those people not going to participate directly in the Developer Meeting at CCC near Berlin. If setting up a "green pathway" connecting to the live meeting on the internet, so the people strongly wanna share their ideas with others will be able to join into the Developer Meeting simultaneously. If there has difficulty in doing such things, maybe recording and uploading the live video of the meeting into the public wiki of the project is another way to share the content and fun of the meeting together with other people all around the world. Thanks. Best Regards, Samuel On Mon, Apr 5, 2010 at 6:00 PM, wrote: > Send baseband-devel mailing list submissions to > baseband-devel at lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request at lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner at lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Developer Meeting in Berlin / 2010-04-10 (Harald Welte) > 2. Re: noisy cable? (Nathan Fain) > > > ---------- Forwarded message ---------- > From: Harald Welte > To: baseband-devel at lists.osmocom.org > Date: Mon, 5 Apr 2010 09:24:45 +0800 > Subject: Developer Meeting in Berlin / 2010-04-10 > Hi all! > > Since I'm returning from holidays in two days, I think it's a good idea > (for those who are in/around Berlin) to meet again at CCC Berlin. > > This is mainly for me to get an idea where we are (compared to before my > holidas) and how we proceed. Especially the loader seems to have made > progress, as far as I can tell from casual reading of the commitlog. > > I'm also curious to see what's happening on the battery charger, sim > card reader (and other) parts of the system. > > I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in > joining, feel free to join! > > Cheers, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > > > > ---------- Forwarded message ---------- > From: Nathan Fain > To: baseband-devel at lists.osmocom.org > Date: Sun, 04 Apr 2010 22:17:38 -0700 > Subject: Re: noisy cable? > fyi, using the /dev/cu.** variant solved my problem of osmocon being > unable to write CMD1 to the port. At least, it worked with an FTDI > cable I built. I imagine it will solve the issue with the prolific > cable as well (will try later). > > > > On 29/03/2010 03:39, willem wrote: > > i managed to get hello_world working on my c121, connected through a > > pl2303 usb/serial cable to my macbookpro. > > > > but found that the connection is extremely noisy. > > often the movement of me putting down the phone on the table is enough > > to break the upload. > > is that a common problem with these headphone/serial cable plugs? > > > > > > for the serial device i can use /dev/cu.PL2303-0000201A > > or /dev/tty.PL2303-0000201A > > > > but when using the '/dev/tty...' variant, i have to add this to > osmocon.c > > > > diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c > > index f934dd7..b361eb1 100644 > > --- a/src/host/osmocon/osmocon.c > > +++ b/src/host/osmocon/osmocon.c > > @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev) > > /* hardware flow control off */ > > options.c_cflag &= ~CRTSCTS; > > > > + /* ignore modem status lines */ > > + options.c_cflag |= CLOCAL; > > + > > /* software flow control off */ > > options.c_iflag &= ~(IXON | IXOFF | IXANY); > > > > ============================= > > > > willem > > > > > > > > > > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel at lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Apr 6 00:00:59 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Apr 2010 08:00:59 +0800 Subject: Developer Meeting in Berlin / 2010-04-10 In-Reply-To: References: Message-ID: <20100406000059.GC25540@prithivi.gnumonks.org> Dear Samuel and others, On Tue, Apr 06, 2010 at 03:59:37AM +0800, Samuel Omlin wrote: > That's a bright idea for all the developers behind the project as well as > those observers around the project to make a brainstorm with the development > and evolution of the project. > > It's a little pity, however, for those people not going to participate > directly in the Developer Meeting at CCC near Berlin. If setting up a "green > pathway" connecting to the live meeting on the internet, so the people > strongly wanna share their ideas with others will be able to join into the > Developer Meeting simultaneously. > > If there has difficulty in doing such things, maybe recording and uploading > the live video of the meeting into the public wiki of the project is another > way to share the content and fun of the meeting together with other people > all around the world. All we are doing is sitting together and chatting about what each of us (most likely no more than 3 or 4 people) have been doing, where we might have been stuck, and what we intend to do next. There is no formal meeting schedule, there is no presentation, there is no preparation of this meeting. Just sitting together and chatting in an informal way. So I really don't see the point of recording or broadcasting any of this. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From samuel.omlin at gmail.com Tue Apr 6 01:53:10 2010 From: samuel.omlin at gmail.com (Samuel Omlin) Date: Tue, 6 Apr 2010 09:53:10 +0800 Subject: Developer Meeting in Berlin / 2010-04-10 In-Reply-To: <20100406000059.GC25540@prithivi.gnumonks.org> References: <20100406000059.GC25540@prithivi.gnumonks.org> Message-ID: Hi Harald, When it comes to the Developer Meeting, something very formal like GOOG I/O most probably immediately comes to minds. Or rather, in the Meeting there should be many folks to attend, different topics with presentations to share and discuss, as well as achievements in the current phase to demonstrate. Therefore, there are the folks interested in the current project like me to desire to take part in the meeting simultaneously even if located in the different places of the world. As a matter of fact, that's just a misunderstanding between one another, (I see) because this is only an informal and local meet-up for those developers behind the project. Finally, hope that you guys will have a good time with the Developer Meeting. :) Thanks. Best Regards, Samuel On Tue, Apr 6, 2010 at 8:00 AM, Harald Welte wrote: > Dear Samuel and others, > > On Tue, Apr 06, 2010 at 03:59:37AM +0800, Samuel Omlin wrote: > > > That's a bright idea for all the developers behind the project as well as > > those observers around the project to make a brainstorm with the > development > > and evolution of the project. > > > > It's a little pity, however, for those people not going to participate > > directly in the Developer Meeting at CCC near Berlin. If setting up a > "green > > pathway" connecting to the live meeting on the internet, so the people > > strongly wanna share their ideas with others will be able to join into > the > > Developer Meeting simultaneously. > > > > If there has difficulty in doing such things, maybe recording and > uploading > > the live video of the meeting into the public wiki of the project is > another > > way to share the content and fun of the meeting together with other > people > > all around the world. > > All we are doing is sitting together and chatting about what each of us > (most likely no more than 3 or 4 people) have been doing, where we might > have been stuck, and what we intend to do next. > > There is no formal meeting schedule, there is no presentation, there is > no preparation of this meeting. Just sitting together and chatting in > an informal way. > > So I really don't see the point of recording or broadcasting any of > this. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Mon Apr 5 15:20:22 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 5 Apr 2010 17:20:22 +0200 Subject: update on layer 3 process Message-ID: hi, the current state of coding can be seen in the src/host/gsm48-andreas/README file of GIT. as noted there, the process of mobility management and call control is completed. this does not mean that it is compiling and working. als debugging has to be completed. the next step would be to follow the compiler errors step by step until all missing and wrong symbols are found and fixed. i will do that later. also the radio ressource is at a point where i like to start integrating it into the layer23 application. today i checked out how the system informations are received and how to send a random access burst. please check out the issues about that at src/host/gsm48-andreas/issues.txt in the GIT. i must note that layer3.c and rslms.c is not needed in my case, since it is part of gsm48_rr.c in order to integrate it, i would like to open a new branch, since there are many other existing files to be expanded. (new structures to header files... see extra.c and extra.h) there must also be a way to get all the changes in the master branch merged to the new branch, so i can react on changes of master branch. i am not that familiar with git, so is there any advice except cherry-picking all the time? or maybe there is a better way of doing that? andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tn150x_hase04f.gif Type: image/gif Size: 6196 bytes Desc: tn150x_hase04f.gif URL: From spaar at mirider.augusta.de Mon Apr 5 17:46:04 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 05 Apr 2010 17:46:04 CEST Subject: AW: Developer Meeting in Berlin / 2010-04-10 Message-ID: <4bba21dc.mirider@mirider.augusta.de> Hello Andreas, On Mon, 5 Apr 2010 17:20:24 +0200, "Andreas.Eversberg" wrote: > > i would like to participate (and others maybe too). what if we have > somethink like a conference for all the people not in berlin? > > in our company we do it this way: > > - a conference number is dialed by all members. > - a phone with hands free option can be used on one place where multiple > members are. > - netmeeting is used for presentation. this can also be via VNC remote > desktop. A conference call sounds good. If it is done this way, I would participate too. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From thegrugq at gmail.com Mon Apr 5 18:13:47 2010 From: thegrugq at gmail.com (the grugq) Date: Tue, 6 Apr 2010 01:13:47 +0700 Subject: AW: Developer Meeting in Berlin / 2010-04-10 In-Reply-To: <4bba21dc.mirider@mirider.augusta.de> References: <4bba21dc.mirider@mirider.augusta.de> Message-ID: <65DC9FBC-BDC1-4499-A0EF-F2FD89157451@gmail.com> I'd also like a conference call. Only I'd like to suggest using a Skype conference call. Calls to Berlin can be expensive if they last an hour or more. --gq On 5 Apr 2010, at 22:46, Dieter Spaar wrote: > Hello Andreas, > > On Mon, 5 Apr 2010 17:20:24 +0200, "Andreas.Eversberg" wrote: >> >> i would like to participate (and others maybe too). what if we have >> somethink like a conference for all the people not in berlin? >> >> in our company we do it this way: >> >> - a conference number is dialed by all members. >> - a phone with hands free option can be used on one place where multiple >> members are. >> - netmeeting is used for presentation. this can also be via VNC remote >> desktop. > > A conference call sounds good. If it is done this way, I would participate > too. > > Best regards, > Dieter > -- > Dieter Spaar, Germany spaar at mirider.augusta.de > From laforge at gnumonks.org Tue Apr 6 02:04:58 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Apr 2010 10:04:58 +0800 Subject: AW: Developer Meeting in Berlin / 2010-04-10 In-Reply-To: <65DC9FBC-BDC1-4499-A0EF-F2FD89157451@gmail.com> References: <4bba21dc.mirider@mirider.augusta.de> <65DC9FBC-BDC1-4499-A0EF-F2FD89157451@gmail.com> Message-ID: <20100406020458.GK9818@prithivi.gnumonks.org> On Tue, Apr 06, 2010 at 01:13:47AM +0700, the grugq wrote: > I'd also like a conference call. Only I'd like to suggest using a > Skype conference call. Calls to Berlin can be expensive if they last > an hour or more. sorry, but I will never even get anywhere close to this proprietary voip protocol or any of it's non-free implementations. I have no idea if there's any working SIP or H323 setup at the CCC Berlin. As indicated before, I really don't want to turn this into a phone conference. It simply has no point to me. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nat at fains.com Mon Apr 5 19:28:24 2010 From: nat at fains.com (Nathan Fain) Date: Mon, 05 Apr 2010 19:28:24 +0000 Subject: AW: Developer Meeting in Berlin / 2010-04-10 In-Reply-To: <4bba21dc.mirider@mirider.augusta.de> References: <4bba21dc.mirider@mirider.augusta.de> Message-ID: im also up for a conf call in whatever form (but agree skype would be nice). If not that then some way to hear the conversion and add questions a queue in IRC that someone there could relay would also work. I've started working on JTAG and it would be great to discuss this adhoc, get some direction from the group. On Mon, 05 Apr 2010 17:46:04 CEST, "Dieter Spaar" wrote: > Hello Andreas, > > On Mon, 5 Apr 2010 17:20:24 +0200, "Andreas.Eversberg" > wrote: >> >> i would like to participate (and others maybe too). what if we have >> somethink like a conference for all the people not in berlin? >> >> in our company we do it this way: >> >> - a conference number is dialed by all members. >> - a phone with hands free option can be used on one place where multiple >> members are. >> - netmeeting is used for presentation. this can also be via VNC remote >> desktop. > > A conference call sounds good. If it is done this way, I would participate > too. > > Best regards, > Dieter -- cyphunk://cypherpoet.com nathan://squimp.com fain://deadhacker.com From laforge at gnumonks.org Tue Apr 6 02:13:09 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Apr 2010 10:13:09 +0800 Subject: Developer Meeting / IRC Meetings In-Reply-To: References: <4bba21dc.mirider@mirider.augusta.de> Message-ID: <20100406021308.GM9818@prithivi.gnumonks.org> Hi Nathan, > im also up for a conf call in whatever form (but agree skype would be > nice). If not that then some way to hear the conversion and add questions > a queue in IRC that someone there could relay would also work. I've > started working on JTAG and it would be great to discuss this adhoc, get > some direction from the group. Ok, what do you think of the following proposal: 1) We have our meeting in Berlin for the people who happen to be local. 2) We schedule some (regular, e.g. weekly) discussion/Q&A session on IRC where some of the more "senior" project members (like myself) are present. Keeping those two separate seems to make more sense to me. What would be your preferred day of the week for those IRC sessions? I'm extremely flexible as long as it is somewhere between 9am and 10pm German time... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nat at fains.com Tue Apr 6 02:36:34 2010 From: nat at fains.com (Nathan Fain) Date: Tue, 06 Apr 2010 02:36:34 +0000 Subject: Developer Meeting / IRC Meetings In-Reply-To: <20100406021308.GM9818@prithivi.gnumonks.org> References: <4bba21dc.mirider@mirider.augusta.de> <20100406021308.GM9818@prithivi.gnumonks.org> Message-ID: <6b873722b3b7b2fb4cbf76b8506bfb68@squimp.com> IRC is fine. weekly is perhaps more than i can bite at the moment so i can get on biweekly for me but im sure plenty of other people would fit the weekly. any day is fine by me. On Tue, 6 Apr 2010 10:13:09 +0800, Harald Welte wrote: > Hi Nathan, > >> im also up for a conf call in whatever form (but agree skype would be >> nice). If not that then some way to hear the conversion and add >> questions >> a queue in IRC that someone there could relay would also work. I've >> started working on JTAG and it would be great to discuss this adhoc, get >> some direction from the group. > > Ok, what do you think of the following proposal: > > 1) We have our meeting in Berlin for the people who happen to > be local. > > 2) We schedule some (regular, e.g. weekly) discussion/Q&A session on IRC > where some of the more "senior" project members (like myself) are > present. > > Keeping those two separate seems to make more sense to me. > > What would be your preferred day of the week for those IRC sessions? > I'm extremely flexible as long as it is somewhere between 9am and 10pm > German time... -- cyphunk://cypherpoet.com nathan://squimp.com fain://deadhacker.com From laforge at gnumonks.org Thu Apr 8 10:35:52 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Apr 2010 12:35:52 +0200 Subject: IRC Meeting proposal: Monday night 8pm CEST ? In-Reply-To: <6b873722b3b7b2fb4cbf76b8506bfb68@squimp.com> References: <4bba21dc.mirider@mirider.augusta.de> <20100406021308.GM9818@prithivi.gnumonks.org> <6b873722b3b7b2fb4cbf76b8506bfb68@squimp.com> Message-ID: <20100408103552.GN7378@prithivi.gnumonks.org> Hi all, On Tue, Apr 06, 2010 at 02:36:34AM +0000, Nathan Fain wrote: > IRC is fine. weekly is perhaps more than i can bite at the moment so i > can get on biweekly for me but im sure plenty of other people would fit the > weekly. any day is fine by me. ok, so I'd recommend we schedule it at something like 8pm CEST on every monday night. Any objections to that schedule? The idea is that all developers are encouraged to hang out on IRC at that time, so people can ask questions as needed. I will make sure to be there as often as possible. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Thu Apr 8 10:52:39 2010 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Thu, 08 Apr 2010 10:52:39 +0000 Subject: IRC Meeting proposal: Monday night 8pm CEST ? In-Reply-To: <20100408103552.GN7378@prithivi.gnumonks.org> Message-ID: <0014852e196a3888bc0483b77abc@google.com> > ok, so I'd recommend we schedule it at something like 8pm CEST on every > monday night. Any objections to that schedule? Sounds good to me. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From nat at fains.com Sun Apr 11 13:22:33 2010 From: nat at fains.com (Nathan Fain) Date: Sun, 11 Apr 2010 13:22:33 +0000 Subject: IRC Meeting proposal: Monday night 8pm CEST =?UTF-8?Q?=3F?= In-Reply-To: <20100408103552.GN7378@prithivi.gnumonks.org> References: <4bba21dc.mirider@mirider.augusta.de> <20100406021308.GM9818@prithivi.gnumonks.org> <6b873722b3b7b2fb4cbf76b8506bfb68@squimp.com> <20100408103552.GN7378@prithivi.gnumonks.org> Message-ID: <0938fcd9ba1b0a3a2e69fe84f4679fa8@squimp.com> im game. tomorrows meeting ill somewhere that i dont have free network access. will see if i can find a nearby cafe or something to use. after this week though ill be able to make mondays consistently. thanks On Thu, 8 Apr 2010 12:35:52 +0200, Harald Welte wrote: > Hi all, > > On Tue, Apr 06, 2010 at 02:36:34AM +0000, Nathan Fain wrote: > >> IRC is fine. weekly is perhaps more than i can bite at the moment so i >> can get on biweekly for me but im sure plenty of other people would fit >> the >> weekly. any day is fine by me. > > ok, so I'd recommend we schedule it at something like 8pm CEST on every > monday night. Any objections to that schedule? > > The idea is that all developers are encouraged to hang out on IRC at > that time, so people can ask questions as needed. I will make sure to > be there as often as possible. > > Regards, > Harald -- cyphunk://cypherpoet.com nathan://squimp.com fain://deadhacker.com From steve at steve-m.de Mon Apr 5 22:24:15 2010 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 06 Apr 2010 00:24:15 +0200 Subject: Support for the Calypso romloader in osmocon Message-ID: <4BBA630F.6090900@steve-m.de> Hi all, I've added support for the Calypso "non-secure" romloader in my branch steve-m/osmocon. This means we now can execute our code on devices like the Motorola W220, the BenQ A38 (which I've used for development), and the OpenMoko devices (can anyone try to cross-compile osmocon and see if it works?). For more information see in the wiki: http://bb.osmocom.org/trac/wiki/CalypsoRomloader I also added a new model switch for the C140 (-m c140), which automatically adds the "1003" string in the uploaded binary. This is meant for use with proms loader, so now you can upload loader.ramload.bin on the C139/C140 and J100i, and load the application itself with osmoload. Regards, Steve From laforge at gnumonks.org Tue Apr 6 02:09:57 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Apr 2010 10:09:57 +0800 Subject: Support for the Calypso romloader in osmocon In-Reply-To: <4BBA630F.6090900@steve-m.de> References: <4BBA630F.6090900@steve-m.de> Message-ID: <20100406020957.GL9818@prithivi.gnumonks.org> Hi Steve! On Tue, Apr 06, 2010 at 12:24:15AM +0200, Steve Markgraf wrote: > I've added support for the Calypso "non-secure" romloader in my > branch steve-m/osmocon. good news! I'll review the branch asap. > This means we now can execute our code on devices like the Motorola > W220, the BenQ A38 (which I've used for development), and the > OpenMoko devices (can anyone try to cross-compile osmocon and see if > it works?). You actually don't have to try to cross-compile as the IRDA UART of the Calypso in the Openmoko is attached to the earphone jack, just like in the non-smartphone calypso designs. But sure, it would be great to test it on both the MODEM UART (from the s3c24xx side) and from the IRDA UART / earphone jack. > For more information see in the wiki: > http://bb.osmocom.org/trac/wiki/CalypsoRomloader thanks a lot, I've started to read through it. > I also added a new model switch for the C140 (-m c140), which > automatically adds the "1003" string in the uploaded binary. ... assuming that nothing important is at the respective address in the image, I suppose? Do we have a way (by linker script tricks?) to ensure that there is some bogus data at that location? Last time I checked, I could not figure out a way to tell the linker "start filling .text from address A to B, then exclude B to C and continue filling from C upwards". -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Tue Apr 6 12:19:20 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 6 Apr 2010 14:19:20 +0200 Subject: questions about layer 1 interface Message-ID: hi, currently i am working on radio ressource layer and the sub processes for 1) network selection, 2) cell selection, and 3) location update trigger process. i have problems expecially with the cell selection task. since it requires measurements and detection of carriers (for some time depending on the slot configuration), it must work together with the layer 1 (radio part). here are some examples of messages what i think must exist between layer 1 and cell selection process: (the primitive names are just examples and do not conform to GSM specs.) L1CTL_DM_EST_REQ (which already exists) tune to a channel in dedicated mode (by given channel, frequency and later hopping sequence) L1CTL_IM_EST_REQ tune to a BCCH channel in idle mode (by given frequency) L1CTL_IM_EST_CNF confirm valid carrier signal. L1CTL_IM_INFO_IND info when reading of BCCH was enough for a cell selection (depends on the channel configuration), shall include measurement L1CTL_MEAS_IND periodic info of measurements from the selected channel. (required for cell reselection) take these only as examples, not as required messages. while reading GSM 05.08, this is what i think is required to do cell (re-)selection process or abort radio connection if fails (below minimum level). any help/ideas/suggestions? andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Apr 8 03:18:15 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Apr 2010 05:18:15 +0200 Subject: questions about layer 1 interface In-Reply-To: References: Message-ID: <20100408031814.GI7378@prithivi.gnumonks.org> Hi Andreas, On Tue, Apr 06, 2010 at 02:19:20PM +0200, Andreas.Eversberg wrote: > currently i am working on radio ressource layer and the sub processes > for 1) network selection, 2) cell selection, and 3) location update > trigger process. Andreas, as indicated in my other mail, I am currently working on those parts that are needed for cell (re)selection anyway, so it would be good to not duplicate work here. However, the required changes to our current layer1 are probably a bit more than I hoped for, so it definitely won't be ready in a day or two. Meanwhile, if you want to test location updating and other higher level parts, I suggest you simply use a fixed ARFCN for testing. Please also note that the current lapdm.c code is far from being complete, there are no retransmissions, etc. yet. Also, layer1 TX side still has a problem where it transmits the bursts all off-by-one timeslot, i.e. only 3 out of 4 bursts of a message are received correctly by the BTS, the other burst is sent at a different (wrong!) point in time, disturbing some other phone on the same cell. But as indicated, I was on holidays for four weeks, so everything is quite stalled. Harald. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Thu Apr 8 08:05:39 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 08 Apr 2010 08:05:39 CEST Subject: questions about layer 1 interface Message-ID: <4bbd8e54.mirider@mirider.augusta.de> Hello Harald, On Thu, 8 Apr 2010 05:18:15 +0200, "Harald Welte" wrote: > > Also, layer1 TX side still has a problem where it transmits the bursts > all off-by-one timeslot, i.e. only 3 out of 4 bursts of a message are > received correctly by the BTS, the other burst is sent at a different > (wrong!) point in time, disturbing some other phone on the same cell. With my fix from a while ago sending works as expected. In the meantime I extended my test code so that I could also verify the correct behaviour against a GSM test set when doing a Location Update. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Wed Apr 7 07:47:56 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Apr 2010 09:47:56 +0200 Subject: gsm48-andreas / issues.txt Message-ID: <20100407074756.GL20583@prithivi.gnumonks.org> Hi Andreas, some comments to your issues.txt: > How do we send MEASUREMENT RESULTS to RSL? (maybe RSL_MT_MEAS_RES) > what triggers the sending? Or do we just send it from time to time to > layer 1 where it is stored and sent when the time is right? (Then we > might get something like RSL_MT_MEAS_CNF, so we can send the next one, > if we have new measurements available, otherwhise the L1 will use the > old measurement results and resends them without confirming it.) measurement results are sent on the SACCH. The Layer1 has independent transmit queues for the main channel (SDCCH/TCH) and its associated SACCH. So the L23 code needs to send the respective packet to a chan_nr/link_id that indicates transmission over the SACCH. In the GSM TS, there is a primitive by which L1 can indicate that it needs the next L23 message for a given channel, which we don't implement (as we're tunnelling L1CTL through HDLC/serial, the answer would never be back before the next TDMA frame anyway). My suggestion would be: Have a fixed SACCH queue depth of 1 or 2 in L1CTL, and every time we actually dequeue the frame (i.e. send it to the DSP), send an indication of the current queue depth up to L23. We should do this for both the main and the ACCH queue so higher layers can implement some kind of flow control if they want. > I need some RACH primitives like: > - RACH request (tx_ph_rach_req already exists) including value and > offset of RACH slot from now. What exactly do you mean with 'value and offset of RACH slot from now'? As we're operating asynchronously "now" is not defined precisely. I think if you simply tell the L1 that you want to transmit at a specified GSM time (modulo 51), we can schedule it that way. L23 should understand the current CCCH/BCCH layout and determine which lsots are applicable for RACH burst transmission. They can then either say "please transmit at this full gsm time (uint32_t of the frame number)" or "please transmit in next multiframe at fn % 51 == X where X is something specified by L23" > - RACH confirm, the RACK has been sent (with timeslot where is was sent) that should be relatively easy to add, I'll add it during the next days. Meanwhile we can simply assume that it was sent at the timeslot as requested. > Since RACH request must be queued in layer 1 until it the right slot > is reached, I need to tell L1 to cancel it. Whenever I receive a > confirm, I schedule the next one until the maximum number has been > transmitted or until an IMMEDIATE ASSIGNMENT is received on CCCH. I think we can ignore that for now. In the worst case, we send one more RACH request than needed. I know this is dangerous if done by many phones on real networks, but for our current goal of "getting something working in our own gsm test network" this is the kind of shortcut we can take. I know your development style is very different. You seem to be trying to implement something thats fully compliant with the spec. I usually try to take a more incremental/iterative approach. Make something work first, and then iteratively improve/complete it. I hope you can live with the fact that at least for now, L1 doesn't have this support. If you want, we can already define the L1CTL message for it but simply ignore it on L1 until its implemented. > RACH request on RSL: > Does it make sense to put RACH request to the set of RSLms primitives? > (i.e. RSL_MT_CHAN_REQ, not RQD!, RSL_MT_CHAN_CNF, RSL_MT_CHAN_CAN) > What do you say? I think we should mark them explicitly as RSLms_MT_* to make it obvious that it is non-standard RSL. Otherwise, I agree. "CAN" for "CANCEL" is probably causing misunderstanding, lets just write the full word. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Apr 7 07:51:58 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Apr 2010 09:51:58 +0200 Subject: gsm48-andreas / issues.txt In-Reply-To: <20100407074756.GL20583@prithivi.gnumonks.org> References: <20100407074756.GL20583@prithivi.gnumonks.org> Message-ID: <20100407075158.GA7378@prithivi.gnumonks.org> Some more feedback: > When SIM is "NOT UPDATED", there is no valid LAI in SIM. LOCATION > UPDATING REQUEST message requires LAI. How is an IMSI attach possible, > if no LAI exists? We have three conditions: > - LAI in SIM is valid > - LAI in SIM exists (last stored) but marked invalid. > - No LAI in SIM (brand new one) > See Table 10.5.3 TS 04.08 and try to understand the riddle... The LAI in the location updating request is not the LAI of the location area you want to attach to. It is the LAI of the LA that you _previously_ were registered to. As such, if there is no [valid] LAI in the SIM, we simply mark it as all-zero (or maybe there's some magic LAC value like 0xfffe, I think Zecke once mentioned something like this) to indicate and invalid LAC. Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Apr 8 08:51:55 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 8 Apr 2010 10:51:55 +0200 Subject: merging prom/pending code (manifest) Message-ID: <20100408085155.GK7378@prithivi.gnumonks.org> Hi Prom! I've now merged (a rebased version of) your prom/pending, including the manifest part. Only one minor issue that I've noticed: 'make clean' does not remove the board/*/*.manifest.o files. Maybe you can fix that at some point. Also, I think it would be better to only export a 'struct manifest' that then has members for all the various parameters (so far only strings with versions, but there might be more stuff in the future). Thanks, Harald. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Apr 9 06:11:53 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Apr 2010 08:11:53 +0200 Subject: Fix building of layer23 against in-tree libosmocore Message-ID: <20100409061153.GB14576@prithivi.gnumonks.org> Hi all! As Andreas has pointed out to me in a phone call yesterday and steve-m mentioned on IRC: Building layer23 with the not-installed (make install) libosmocore from osmocom-bb resulted in link failures. I've now addressed those problems and the repo should be building just fine again. Regards, Harald. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vogelchr at vogel.cx Fri Apr 9 13:35:00 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Fri, 9 Apr 2010 15:35:00 +0200 Subject: PATCH: 5x8 font Message-ID: <20100409133458.GA20983@vogel.cx> Hi, I converted the X font 5x8 for use in BB and added an goto_xy routine in case anyone wants to put something entertaining on the LCD (besides Hello World). Compared to the old 8x8 font.. - doesn't miss the topmost line of pixels :-) - needs 475 bytes instead of 4k (only includes characters ASCII 32 .. 126) - allows for 19x8 characters on the screen hello_world.bin prints out all glyphs for testing. Applies to current "master" (as of 9.4.2010/15:30 MESZ). Chris -------------- next part -------------- commit 6fb802f82715f47cb4bb5df6609afaecb6875d09 Author: Christian Vogel Date: Fri Apr 9 15:21:34 2010 +0200 Added 5x8 font from debian/Ubuntu xfonts-base: - memory footprint from 4k to 480 bytes (compared to 8x8) - 8lines x 19chars on the C123 LCD Added display_goto_xy globally, and an implementation for the C123 LCD controller (st7558) diff --git a/src/target/firmware/Makefile b/src/target/firmware/Makefile index 7c6ba7a..cd46267 100644 --- a/src/target/firmware/Makefile +++ b/src/target/firmware/Makefile @@ -4,7 +4,8 @@ INCLUDES=-Iinclude/ -I../../../include -I../../shared/libosmocore/include # Various objects that are currently linked into all applications FLASH_OBJS=flash/cfi_flash.o -DISPLAY_OBJS=display/font_r8x8.o display/font_r8x8_horiz.o display/st7558.o display/ssd1783.o display/display.o +DISPLAY_OBJS=display/font_r8x8.o display/font_r8x8_horiz.o display/st7558.o display/ssd1783.o display/display.o \ + display/xfont_5x8_32_to_128.o ABB_OBJS=abb/twl3025.o RF_OBJS=rf/trf6151.o diff --git a/src/target/firmware/apps/hello_world/main.c b/src/target/firmware/apps/hello_world/main.c index d1a566b..5cc7a32 100644 --- a/src/target/firmware/apps/hello_world/main.c +++ b/src/target/firmware/apps/hello_world/main.c @@ -84,6 +84,9 @@ static void l1a_l23_rx_cb(uint8_t dlci, struct msgb *msg) int main(void) { + int i; + unsigned char buf[19]; + board_init(); puts("\n\nHello World from " __FILE__ " program code\n"); puts(hr); @@ -110,7 +113,24 @@ int main(void) #endif display_set_attr(DISP_ATTR_INVERT); - display_puts("Hello World"); + + display_puts("Hello World from \\/"); + display_goto_xy(0,1); + display_puts("OSMOCOM baseband /\\"); + + buf[0]='<'; + buf[17]='>'; + buf[18]='\0'; + + for(i=32;i<128;i++){ + int x=i%16; + int y=i/16; + if(x==0) + display_goto_xy(0,y); + buf[x+1]=i; + if(x==15) + display_puts(buf); + } sercomm_register_rx_cb(SC_DLCI_CONSOLE, console_rx_cb); sercomm_register_rx_cb(SC_DLCI_L1A_L23, l1a_l23_rx_cb); diff --git a/src/target/firmware/display/st7558.c b/src/target/firmware/display/st7558.c index baed9eb..d2162cd 100644 --- a/src/target/firmware/display/st7558.c +++ b/src/target/firmware/display/st7558.c @@ -34,7 +34,7 @@ #define CONTROL_RS_RAM 0x40 #define CONTROL_RS_CMD 0x00 #define Y_ADDR(n) (0x40|((n)&0xf)) -#define X_ADDR(n) (0x80|((n)&0x3f)) +#define X_ADDR(n) (0x80|((n)&0x7f)) static const uint8_t setup[] = { CONTROL_RS_CMD, 0x2e, 0x21, 0x12, 0xc0, 0x0b, 0x20, 0x11, 0x00, 0x40, 0x80 }; static const uint8_t home[] = { CONTROL_RS_CMD, Y_ADDR(0), X_ADDR(0) }; @@ -101,15 +101,29 @@ static void *mcpy(uint8_t *dst, const uint8_t *src, int len) return dst; } -extern const unsigned char fontdata_r8x8[]; +extern const unsigned char fontdata_5x8_fixed[]; + +static void st7558_goto_xy(int xpos,int ypos) +{ + uint8_t gotoxy_buf[3]; + + gotoxy_buf[0]=CONTROL_RS_CMD; + gotoxy_buf[1]=X_ADDR(xpos * 8 /* bytes per char */); + gotoxy_buf[2]=Y_ADDR(ypos); + st7558_write(gotoxy_buf,3); +} static void st7558_putc(unsigned char c) { uint8_t putc_buf[16]; - uint8_t bytes_per_char = 8; + uint8_t bytes_per_char = 5; + + if(c<32 || c>126) + c='?'; + c -= 32; /* we only store ascii 32 .. 127 */ putc_buf[0] = CONTROL_RS_RAM; - mcpy(putc_buf+1, fontdata_r8x8+(c*bytes_per_char), bytes_per_char); + mcpy(putc_buf+1, fontdata_5x8_fixed+(c*bytes_per_char), bytes_per_char); st7558_write(putc_buf, 1+bytes_per_char); } @@ -119,5 +133,7 @@ const struct display_driver st7558_display = { .clrscr = &st7558_clrscr, .set_attr = &st7558_set_attr, .unset_attr = &st7558_unset_attr, + .goto_xy = &st7558_goto_xy, .putc = &st7558_putc, }; + diff --git a/src/target/firmware/display/xfont_5x8_32_to_128.c b/src/target/firmware/display/xfont_5x8_32_to_128.c new file mode 100644 index 0000000..31fab0d --- /dev/null +++ b/src/target/firmware/display/xfont_5x8_32_to_128.c @@ -0,0 +1,575 @@ + +const unsigned char fontdata_5x8_fixed[]={ + +/* char ' ' +--------+ */ + 0x00, /* | | */ + 0x00, /* | | */ + 0x00, /* | | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char '!' +--------+ */ + 0x00, /* | | */ + 0x00, /* | | */ + 0x5e, /* | @ @@@@ | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char '"' +--------+ */ + 0x00, /* | | */ + 0x0e, /* | @@@ | */ + 0x00, /* | | */ + 0x0e, /* | @@@ | */ + 0x00, /* | | */ +/* char '#' +--------+ */ + 0x14, /* | @ @ | */ + 0x7f, /* | @@@@@@@| */ + 0x14, /* | @ @ | */ + 0x7f, /* | @@@@@@@| */ + 0x14, /* | @ @ | */ +/* char '$' +--------+ */ + 0x04, /* | @ | */ + 0x2a, /* | @ @ @ | */ + 0x7f, /* | @@@@@@@| */ + 0x2a, /* | @ @ @ | */ + 0x10, /* | @ | */ +/* char '%' +--------+ */ + 0x00, /* | | */ + 0x16, /* | @ @@ | */ + 0x08, /* | @ | */ + 0x34, /* | @@ @ | */ + 0x00, /* | | */ +/* char '&' +--------+ */ + 0x36, /* | @@ @@ | */ + 0x49, /* | @ @ @| */ + 0x36, /* | @@ @@ | */ + 0x40, /* | @ | */ + 0x00, /* | | */ +/* char ''' +--------+ */ + 0x00, /* | | */ + 0x00, /* | | */ + 0x0e, /* | @@@ | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char '(' +--------+ */ + 0x00, /* | | */ + 0x3c, /* | @@@@ | */ + 0x42, /* | @ @ | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char ')' +--------+ */ + 0x00, /* | | */ + 0x42, /* | @ @ | */ + 0x3c, /* | @@@@ | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char '*' +--------+ */ + 0x54, /* | @ @ @ | */ + 0x38, /* | @@@ | */ + 0x38, /* | @@@ | */ + 0x54, /* | @ @ @ | */ + 0x00, /* | | */ +/* char '+' +--------+ */ + 0x10, /* | @ | */ + 0x10, /* | @ | */ + 0x7c, /* | @@@@@ | */ + 0x10, /* | @ | */ + 0x10, /* | @ | */ +/* char ',' +--------+ */ + 0x00, /* | | */ + 0x80, /* |@ | */ + 0x60, /* | @@ | */ + 0x20, /* | @ | */ + 0x00, /* | | */ +/* char '-' +--------+ */ + 0x10, /* | @ | */ + 0x10, /* | @ | */ + 0x10, /* | @ | */ + 0x10, /* | @ | */ + 0x00, /* | | */ +/* char '.' +--------+ */ + 0x00, /* | | */ + 0x40, /* | @ | */ + 0xe0, /* |@@@ | */ + 0x40, /* | @ | */ + 0x00, /* | | */ +/* char '/' +--------+ */ + 0x60, /* | @@ | */ + 0x10, /* | @ | */ + 0x08, /* | @ | */ + 0x06, /* | @@ | */ + 0x00, /* | | */ +/* char '0' +--------+ */ + 0x00, /* | | */ + 0x3c, /* | @@@@ | */ + 0x42, /* | @ @ | */ + 0x3c, /* | @@@@ | */ + 0x00, /* | | */ +/* char '1' +--------+ */ + 0x00, /* | | */ + 0x44, /* | @ @ | */ + 0x7e, /* | @@@@@@ | */ + 0x40, /* | @ | */ + 0x00, /* | | */ +/* char '2' +--------+ */ + 0x64, /* | @@ @ | */ + 0x52, /* | @ @ @ | */ + 0x52, /* | @ @ @ | */ + 0x4c, /* | @ @@ | */ + 0x00, /* | | */ +/* char '3' +--------+ */ + 0x22, /* | @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x4e, /* | @ @@@ | */ + 0x32, /* | @@ @ | */ + 0x00, /* | | */ +/* char '4' +--------+ */ + 0x18, /* | @@ | */ + 0x14, /* | @ @ | */ + 0x7e, /* | @@@@@@ | */ + 0x10, /* | @ | */ + 0x00, /* | | */ +/* char '5' +--------+ */ + 0x2e, /* | @ @@@ | */ + 0x4a, /* | @ @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x32, /* | @@ @ | */ + 0x00, /* | | */ +/* char '6' +--------+ */ + 0x3c, /* | @@@@ | */ + 0x4a, /* | @ @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x30, /* | @@ | */ + 0x00, /* | | */ +/* char '7' +--------+ */ + 0x02, /* | @ | */ + 0x62, /* | @@ @ | */ + 0x1a, /* | @@ @ | */ + 0x06, /* | @@ | */ + 0x00, /* | | */ +/* char '8' +--------+ */ + 0x34, /* | @@ @ | */ + 0x4a, /* | @ @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x34, /* | @@ @ | */ + 0x00, /* | | */ +/* char '9' +--------+ */ + 0x0c, /* | @@ | */ + 0x52, /* | @ @ @ | */ + 0x52, /* | @ @ @ | */ + 0x3c, /* | @@@@ | */ + 0x00, /* | | */ +/* char ':' +--------+ */ + 0x00, /* | | */ + 0x6c, /* | @@ @@ | */ + 0x6c, /* | @@ @@ | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char ';' +--------+ */ + 0x00, /* | | */ + 0x80, /* |@ | */ + 0x6c, /* | @@ @@ | */ + 0x2c, /* | @ @@ | */ + 0x00, /* | | */ +/* char '<' +--------+ */ + 0x00, /* | | */ + 0x18, /* | @@ | */ + 0x24, /* | @ @ | */ + 0x42, /* | @ @ | */ + 0x00, /* | | */ +/* char '=' +--------+ */ + 0x28, /* | @ @ | */ + 0x28, /* | @ @ | */ + 0x28, /* | @ @ | */ + 0x28, /* | @ @ | */ + 0x00, /* | | */ +/* char '>' +--------+ */ + 0x00, /* | | */ + 0x42, /* | @ @ | */ + 0x24, /* | @ @ | */ + 0x18, /* | @@ | */ + 0x00, /* | | */ +/* char '?' +--------+ */ + 0x00, /* | | */ + 0x04, /* | @ | */ + 0x52, /* | @ @ @ | */ + 0x0c, /* | @@ | */ + 0x00, /* | | */ +/* char '@' +--------+ */ + 0x3c, /* | @@@@ | */ + 0x42, /* | @ @ | */ + 0x99, /* |@ @@ @| */ + 0xa5, /* |@ @ @ @| */ + 0x1e, /* | @@@@ | */ +/* char 'A' +--------+ */ + 0x7c, /* | @@@@@ | */ + 0x12, /* | @ @ | */ + 0x12, /* | @ @ | */ + 0x7c, /* | @@@@@ | */ + 0x00, /* | | */ +/* char 'B' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x4a, /* | @ @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x34, /* | @@ @ | */ + 0x00, /* | | */ +/* char 'C' +--------+ */ + 0x3c, /* | @@@@ | */ + 0x42, /* | @ @ | */ + 0x42, /* | @ @ | */ + 0x24, /* | @ @ | */ + 0x00, /* | | */ +/* char 'D' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x42, /* | @ @ | */ + 0x42, /* | @ @ | */ + 0x3c, /* | @@@@ | */ + 0x00, /* | | */ +/* char 'E' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x4a, /* | @ @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x42, /* | @ @ | */ + 0x00, /* | | */ +/* char 'F' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x0a, /* | @ @ | */ + 0x0a, /* | @ @ | */ + 0x02, /* | @ | */ + 0x00, /* | | */ +/* char 'G' +--------+ */ + 0x3c, /* | @@@@ | */ + 0x42, /* | @ @ | */ + 0x52, /* | @ @ @ | */ + 0x34, /* | @@ @ | */ + 0x00, /* | | */ +/* char 'H' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x08, /* | @ | */ + 0x08, /* | @ | */ + 0x7e, /* | @@@@@@ | */ + 0x00, /* | | */ +/* char 'I' +--------+ */ + 0x00, /* | | */ + 0x42, /* | @ @ | */ + 0x7e, /* | @@@@@@ | */ + 0x42, /* | @ @ | */ + 0x00, /* | | */ +/* char 'J' +--------+ */ + 0x20, /* | @ | */ + 0x42, /* | @ @ | */ + 0x3e, /* | @@@@@ | */ + 0x02, /* | @ | */ + 0x00, /* | | */ +/* char 'K' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x08, /* | @ | */ + 0x34, /* | @@ @ | */ + 0x42, /* | @ @ | */ + 0x00, /* | | */ +/* char 'L' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x40, /* | @ | */ + 0x40, /* | @ | */ + 0x40, /* | @ | */ + 0x00, /* | | */ +/* char 'M' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x0c, /* | @@ | */ + 0x0c, /* | @@ | */ + 0x7e, /* | @@@@@@ | */ + 0x00, /* | | */ +/* char 'N' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x0c, /* | @@ | */ + 0x38, /* | @@@ | */ + 0x7e, /* | @@@@@@ | */ + 0x00, /* | | */ +/* char 'O' +--------+ */ + 0x3c, /* | @@@@ | */ + 0x42, /* | @ @ | */ + 0x42, /* | @ @ | */ + 0x3c, /* | @@@@ | */ + 0x00, /* | | */ +/* char 'P' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x12, /* | @ @ | */ + 0x12, /* | @ @ | */ + 0x0c, /* | @@ | */ + 0x00, /* | | */ +/* char 'Q' +--------+ */ + 0x3c, /* | @@@@ | */ + 0x52, /* | @ @ @ | */ + 0x62, /* | @@ @ | */ + 0xbc, /* |@ @@@@ | */ + 0x00, /* | | */ +/* char 'R' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x12, /* | @ @ | */ + 0x12, /* | @ @ | */ + 0x6c, /* | @@ @@ | */ + 0x00, /* | | */ +/* char 'S' +--------+ */ + 0x24, /* | @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x52, /* | @ @ @ | */ + 0x24, /* | @ @ | */ + 0x00, /* | | */ +/* char 'T' +--------+ */ + 0x00, /* | | */ + 0x02, /* | @ | */ + 0x7e, /* | @@@@@@ | */ + 0x02, /* | @ | */ + 0x00, /* | | */ +/* char 'U' +--------+ */ + 0x3e, /* | @@@@@ | */ + 0x40, /* | @ | */ + 0x40, /* | @ | */ + 0x3e, /* | @@@@@ | */ + 0x00, /* | | */ +/* char 'V' +--------+ */ + 0x1e, /* | @@@@ | */ + 0x60, /* | @@ | */ + 0x60, /* | @@ | */ + 0x1e, /* | @@@@ | */ + 0x00, /* | | */ +/* char 'W' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x30, /* | @@ | */ + 0x30, /* | @@ | */ + 0x7e, /* | @@@@@@ | */ + 0x00, /* | | */ +/* char 'X' +--------+ */ + 0x66, /* | @@ @@ | */ + 0x18, /* | @@ | */ + 0x18, /* | @@ | */ + 0x66, /* | @@ @@ | */ + 0x00, /* | | */ +/* char 'Y' +--------+ */ + 0x06, /* | @@ | */ + 0x08, /* | @ | */ + 0x70, /* | @@@ | */ + 0x08, /* | @ | */ + 0x06, /* | @@ | */ +/* char 'Z' +--------+ */ + 0x62, /* | @@ @ | */ + 0x52, /* | @ @ @ | */ + 0x4a, /* | @ @ @ | */ + 0x46, /* | @ @@ | */ + 0x00, /* | | */ +/* char '[' +--------+ */ + 0x00, /* | | */ + 0x7e, /* | @@@@@@ | */ + 0x42, /* | @ @ | */ + 0x42, /* | @ @ | */ + 0x00, /* | | */ +/* char '\' +--------+ */ + 0x06, /* | @@ | */ + 0x08, /* | @ | */ + 0x10, /* | @ | */ + 0x60, /* | @@ | */ + 0x00, /* | | */ +/* char ']' +--------+ */ + 0x00, /* | | */ + 0x42, /* | @ @ | */ + 0x42, /* | @ @ | */ + 0x7e, /* | @@@@@@ | */ + 0x00, /* | | */ +/* char '^' +--------+ */ + 0x00, /* | | */ + 0x04, /* | @ | */ + 0x02, /* | @ | */ + 0x04, /* | @ | */ + 0x00, /* | | */ +/* char '_' +--------+ */ + 0x80, /* |@ | */ + 0x80, /* |@ | */ + 0x80, /* |@ | */ + 0x80, /* |@ | */ + 0x00, /* | | */ +/* char '`' +--------+ */ + 0x00, /* | | */ + 0x02, /* | @ | */ + 0x04, /* | @ | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char 'a' +--------+ */ + 0x30, /* | @@ | */ + 0x48, /* | @ @ | */ + 0x48, /* | @ @ | */ + 0x78, /* | @@@@ | */ + 0x00, /* | | */ +/* char 'b' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x48, /* | @ @ | */ + 0x48, /* | @ @ | */ + 0x30, /* | @@ | */ + 0x00, /* | | */ +/* char 'c' +--------+ */ + 0x00, /* | | */ + 0x30, /* | @@ | */ + 0x48, /* | @ @ | */ + 0x48, /* | @ @ | */ + 0x00, /* | | */ +/* char 'd' +--------+ */ + 0x30, /* | @@ | */ + 0x48, /* | @ @ | */ + 0x48, /* | @ @ | */ + 0x7e, /* | @@@@@@ | */ + 0x00, /* | | */ +/* char 'e' +--------+ */ + 0x30, /* | @@ | */ + 0x68, /* | @@ @ | */ + 0x58, /* | @ @@ | */ + 0x10, /* | @ | */ + 0x00, /* | | */ +/* char 'f' +--------+ */ + 0x10, /* | @ | */ + 0x7c, /* | @@@@@ | */ + 0x12, /* | @ @ | */ + 0x04, /* | @ | */ + 0x00, /* | | */ +/* char 'g' +--------+ */ + 0x10, /* | @ | */ + 0xa8, /* |@ @ @ | */ + 0xa8, /* |@ @ @ | */ + 0x70, /* | @@@ | */ + 0x00, /* | | */ +/* char 'h' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x08, /* | @ | */ + 0x08, /* | @ | */ + 0x70, /* | @@@ | */ + 0x00, /* | | */ +/* char 'i' +--------+ */ + 0x00, /* | | */ + 0x48, /* | @ @ | */ + 0x7a, /* | @@@@ @ | */ + 0x40, /* | @ | */ + 0x00, /* | | */ +/* char 'j' +--------+ */ + 0x00, /* | | */ + 0x40, /* | @ | */ + 0x80, /* |@ | */ + 0x7a, /* | @@@@ @ | */ + 0x00, /* | | */ +/* char 'k' +--------+ */ + 0x7e, /* | @@@@@@ | */ + 0x10, /* | @ | */ + 0x10, /* | @ | */ + 0x68, /* | @@ @ | */ + 0x00, /* | | */ +/* char 'l' +--------+ */ + 0x00, /* | | */ + 0x42, /* | @ @ | */ + 0x7e, /* | @@@@@@ | */ + 0x40, /* | @ | */ + 0x00, /* | | */ +/* char 'm' +--------+ */ + 0x78, /* | @@@@ | */ + 0x08, /* | @ | */ + 0x70, /* | @@@ | */ + 0x08, /* | @ | */ + 0x70, /* | @@@ | */ +/* char 'n' +--------+ */ + 0x78, /* | @@@@ | */ + 0x08, /* | @ | */ + 0x08, /* | @ | */ + 0x70, /* | @@@ | */ + 0x00, /* | | */ +/* char 'o' +--------+ */ + 0x30, /* | @@ | */ + 0x48, /* | @ @ | */ + 0x48, /* | @ @ | */ + 0x30, /* | @@ | */ + 0x00, /* | | */ +/* char 'p' +--------+ */ + 0xf8, /* |@@@@@ | */ + 0x28, /* | @ @ | */ + 0x28, /* | @ @ | */ + 0x10, /* | @ | */ + 0x00, /* | | */ +/* char 'q' +--------+ */ + 0x10, /* | @ | */ + 0x28, /* | @ @ | */ + 0x28, /* | @ @ | */ + 0xf8, /* |@@@@@ | */ + 0x00, /* | | */ +/* char 'r' +--------+ */ + 0x78, /* | @@@@ | */ + 0x10, /* | @ | */ + 0x08, /* | @ | */ + 0x10, /* | @ | */ + 0x00, /* | | */ +/* char 's' +--------+ */ + 0x00, /* | | */ + 0x50, /* | @ @ | */ + 0x58, /* | @ @@ | */ + 0x28, /* | @ @ | */ + 0x00, /* | | */ +/* char 't' +--------+ */ + 0x08, /* | @ | */ + 0x3e, /* | @@@@@ | */ + 0x48, /* | @ @ | */ + 0x20, /* | @ | */ + 0x00, /* | | */ +/* char 'u' +--------+ */ + 0x38, /* | @@@ | */ + 0x40, /* | @ | */ + 0x40, /* | @ | */ + 0x78, /* | @@@@ | */ + 0x00, /* | | */ +/* char 'v' +--------+ */ + 0x00, /* | | */ + 0x38, /* | @@@ | */ + 0x40, /* | @ | */ + 0x38, /* | @@@ | */ + 0x00, /* | | */ +/* char 'w' +--------+ */ + 0x38, /* | @@@ | */ + 0x40, /* | @ | */ + 0x30, /* | @@ | */ + 0x40, /* | @ | */ + 0x38, /* | @@@ | */ +/* char 'x' +--------+ */ + 0x48, /* | @ @ | */ + 0x30, /* | @@ | */ + 0x30, /* | @@ | */ + 0x48, /* | @ @ | */ + 0x00, /* | | */ +/* char 'y' +--------+ */ + 0x58, /* | @ @@ | */ + 0xa0, /* |@ @ | */ + 0xa0, /* |@ @ | */ + 0x78, /* | @@@@ | */ + 0x00, /* | | */ +/* char 'z' +--------+ */ + 0x48, /* | @ @ | */ + 0x68, /* | @@ @ | */ + 0x58, /* | @ @@ | */ + 0x48, /* | @ @ | */ + 0x00, /* | | */ +/* char '{' +--------+ */ + 0x08, /* | @ | */ + 0x2a, /* | @ @ @ | */ + 0x55, /* | @ @ @ @| */ + 0x41, /* | @ @| */ + 0x00, /* | | */ +/* char '|' +--------+ */ + 0x00, /* | | */ + 0x00, /* | | */ + 0x7e, /* | @@@@@@ | */ + 0x00, /* | | */ + 0x00, /* | | */ +/* char '}' +--------+ */ + 0x41, /* | @ @| */ + 0x55, /* | @ @ @ @| */ + 0x2a, /* | @ @ @ | */ + 0x08, /* | @ | */ + 0x00, /* | | */ +/* char '~' +--------+ */ + 0x04, /* | @ | */ + 0x02, /* | @ | */ + 0x04, /* | @ | */ + 0x02, /* | @ | */ + 0x00 /* | | */ +/* +--------+ */ +}; diff --git a/src/target/firmware/include/display.h b/src/target/firmware/include/display.h index b49ae7b..0ba7a4c 100644 --- a/src/target/firmware/include/display.h +++ b/src/target/firmware/include/display.h @@ -39,6 +39,12 @@ static inline int display_putchar(unsigned char c) { return display->putc(c); } + +static inline void display_goto_xy(int xpos,int ypos) +{ + display->goto_xy(xpos,ypos); +} + int display_puts(const char *s); extern const struct display_driver st7558_display; From laforge at gnumonks.org Sat Apr 10 07:26:05 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Apr 2010 09:26:05 +0200 Subject: PATCH: 5x8 font In-Reply-To: <20100409133458.GA20983@vogel.cx> References: <20100409133458.GA20983@vogel.cx> Message-ID: <20100410072605.GA14576@prithivi.gnumonks.org> Hi Christian, first of all thanks for your patch. I think it is great to have a better/smaller font. However, I cannot merge the patch as-is, as I have the following comments: 1) we need a way to select between individual fonts when writing to the display. I think in the long run it is inevitable that we'll use small and big letters on screen and have to select/ switch between them. Something like display_select_font(FONT_5x8) to be called before a display_puts() sounds like a reasonable API for this. 2) Removing all the special characters might not be the best idea to do. If at all, it should be a compile time option whether or not to drop the special characters. Also, the check for replacing a character with '?' needs to be a font-specific and not a global decision. 3) introducing the new font should be one patch, fixing the 'miss topmost line' another patch, and any experimental changes to hello_world/main.c should be yet another patch. This way we can keep the commitlog a bit more clean. I hope you're willing to rework your code, thanks in advance! Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vogelchr at vogel.cx Sat Apr 10 14:46:48 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Sat, 10 Apr 2010 17:46:48 +0300 Subject: PATCH: 5x8 font In-Reply-To: <20100410072605.GA14576@prithivi.gnumonks.org> References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> Message-ID: Hi Harald, thanks for your comments. I'll address them below. On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte wrote: > 1) we need a way to select between individual fonts when writing > to the display. I think in the long run it is inevitable that > we'll use small and big letters on screen and have to select/ > switch between them. > Something like display_select_font(FONT_5x8) to be called > before a display_puts() sounds like a reasonable API for this. I completely agree. The motivation for my (first) patch was mainly to have *something* on the screen (e.g. serial port Rx/Tx bytes, whatever) and that needs just a usable font and gotoxy. I never considered it a final UI library. But if we want to do it proper, I have a few question to you and the list: - If we stick to multiple-of-8-high fonts (at least on the C128) we can just blindly write at the proper location. The C155 (?) might have different restrictions. Is this ok or should we try to support arbitrary sized fonts? - If we want to support arbitrary sized fonts, we either should buffer the display in RAM (might be wasteful on high res color displays?) or read/modify/write over i2c (might be slow, occupy the bus for too long). What's your opinion on that? - Which font-encoding should we use? I know that GSM 03.38 specifies the encoding used for SMSs, but should we stick with that for on-screen output? It's not ASCII compatible regarding []{}\... Note: in IRC told me that prom is probably already working on that? Is he reading the list? prom, can you confirm? > 2) Removing all the special characters might not be the best idea to do. > If at all, it should be a compile time option whether or not to drop > the special characters. > Also, the check for replacing a character with '?' needs to be > a font-specific and not a global decision. I agree, see also 3rd tick-mark above. > 3) introducing the new font should be one patch, fixing the 'miss > topmost line' another patch, and any experimental changes to > hello_world/main.c should be yet another patch. This way we > can keep the commitlog a bit more clean. OK, I agree with that. Btw: fixing the topmost line in the 8x8 font will have to be done by whoever contributed the 8x8 font in the first place :-) Greetings from Bavaria, Chris From laforge at gnumonks.org Sun Apr 11 05:48:51 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Apr 2010 07:48:51 +0200 Subject: PATCH: 5x8 font In-Reply-To: References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> Message-ID: <20100411054851.GI3284@prithivi.gnumonks.org> Hi Christian, On Sat, Apr 10, 2010 at 05:46:48PM +0300, Christian Vogel wrote: > But if we want to do it proper, I have a few question to you and the list: > > - If we stick to multiple-of-8-high fonts (at least on the C128) we > can just blindly write at the proper location. The C155 (?) might > have different restrictions. Is this ok or should we try to support > arbitrary sized fonts? we need arbitrary sized fonts :( > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) > or read/modify/write over i2c (might be slow, occupy the bus for too > long). What's your opinion on that? yes, we need a memory frame buffer that is periodically synchronized (if any changes have happened) to the real device by means of a low-priority task. > - Which font-encoding should we use? I know that GSM 03.38 specifies > the encoding used for SMSs, but should we stick with that for > on-screen output? It's not ASCII compatible regarding []{}\... I think we should use ASCII for screen output despite what the GSM standard alphabet does. libosmocore already has conversion functions I believe. > Note: > in IRC told me that prom is probably already working on that? > Is he reading the list? prom, can you confirm? He's reading the list and the plan was to commit his unfinished code to a branch in the repository. > OK, I agree with that. Btw: fixing the topmost line in the 8x8 font > will have to be done by whoever contributed the 8x8 font in the > first place :-) ah, ok, that would be me. I still have the perl script somewhwere that was used to generate the code. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Sat Apr 10 00:25:58 2010 From: steve at steve-m.de (Steve Markgraf) Date: Sat, 10 Apr 2010 02:25:58 +0200 Subject: fix: disabling romloader on romload-targets Message-ID: <4BBFC596.6040003@steve-m.de> Hi, when I tried to read the secure-romloader of an Alcatel VLE5-series phone, I noticed a small bug in calypso_bootrom(), which prom already tried to fix, but his fix only worked on targets which have nIBOOT tied to high (Compal). I've committed a fix for this to steve-m/pending. Regards, Steve From laforge at gnumonks.org Sat Apr 10 07:17:28 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Apr 2010 09:17:28 +0200 Subject: fix: disabling romloader on romload-targets In-Reply-To: <4BBFC596.6040003@steve-m.de> References: <4BBFC596.6040003@steve-m.de> Message-ID: <20100410071728.GY14576@prithivi.gnumonks.org> Hi Steve, On Sat, Apr 10, 2010 at 02:25:58AM +0200, Steve Markgraf wrote: > when I tried to read the secure-romloader of an Alcatel VLE5-series > phone, I noticed a small bug in calypso_bootrom(), which prom > already tried to fix, but his fix only worked on targets which have > nIBOOT tied to high (Compal). > > I've committed a fix for this to steve-m/pending. thanks, I've merged it. One minor comment: Your commitlog lines seem awfully long, I would like to ask you to wrap them in a format similar as it is used in e-mail messages (at 72..80 characters) in the future. Thanks for your consideration. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Sat Apr 10 13:24:14 2010 From: steve at steve-m.de (Steve Markgraf) Date: Sat, 10 Apr 2010 15:24:14 +0200 Subject: fix: disabling romloader on romload-targets In-Reply-To: <20100410071728.GY14576@prithivi.gnumonks.org> References: <4BBFC596.6040003@steve-m.de> <20100410071728.GY14576@prithivi.gnumonks.org> Message-ID: <4BC07BFE.8050906@steve-m.de> Hi Harald, Harald Welte wrote: > One minor comment: Your commitlog lines seem > awfully long, I would like to ask you to wrap them in a format similar > as it is used in e-mail messages (at 72..80 characters) in the future. > Thanks for your consideration. Thanks for your advice, I'll take that in regard on further commits. Steve From laforge at gnumonks.org Sat Apr 10 09:45:32 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Apr 2010 11:45:32 +0200 Subject: libosmocore development flow Message-ID: <20100410094532.GD14576@prithivi.gnumonks.org> Hi! Andreas has asked me about this, and it might be interesting to a wider audience, so I've added the information to the wiki at https://calypso.gnumonks.org/trac/wiki/libosmocore Here's a copy of what I wrote there: == Development Cycle == As we are still developing the GSM protocol stacks on the network side (OpenBSC) and phone side (OsmocomBB), every so often there is a need to add some new code to libosmocore. Even worse, we sometimes need to break the API and ABI of the library. However, by keeping libosmocore in a separate git repository, we run into one problem: Checking out an old version of e.g. OpenBSC or OsmocomBB will result in failed builds, as we don't remember which old version of libosmocore was required. This makes debugging and things like git bisect very hard to impossible. In order to solve this problem, we use [http://github.com/apenwarr/git-subtree git-subtree] to import the full libosmocore.git repository into OsmocomBB. This way, we ensure that there is always a compatible version of libosmocore inside the tree if we check out old OsmocomBB versions from git. === Making changes to libosmocore === '''NEVER COMMIT CHANGES DIRECTLY TO osmocom-bb.git:src/shared/libosmocore''' Instead, use the following process: 1. make your changes to your local copy of libosmocore 1. test them together with OsmocomBB and OpenBSC 1. test if libosmocore still builds for both host and target (ARM) 1. create a ''diff'' of your local libosmocore changes 1. apply that diff to the libosmocore.git repository 1. use the script in osmocom-bb.git/src/shared/update-libosmocore.sh (uses git-subtree) to import your changes from libosmocore.git 1. test + commit your OsmocomBB changes that depend on the newly introduced code to libosmocore It is important that the steps are followed in the order state above to ensure consistency of our repositories Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Apr 10 21:47:45 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Apr 2010 23:47:45 +0200 Subject: Use OsmocomBB as OpenBTS / airprobe clock generator Message-ID: <20100410214745.GB3284@prithivi.gnumonks.org> Hi! Recently we've had the idea of using OsmocomBB with a simple firmware that synchronizes to an existing GSM networks FCCH and use the resulting 13MHz clock to drive the USRP for airprobe or OpenBTS. Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to multiply it up to the required 52 MHz. However, neither the Openmoko nor the Compal/Motorola phones expose any of the 3 clock output pads :( So the only choice is to use something along the lines of the http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html as a quad clock multiplier and attach it to the CLK13OUT signal of the phone. The chip is available for 9 USD in single quantities at digikey, and possibly cheaper at other sources. Combined with a sub-20EUR phone it might be a very cheap but still accurate frequency source for OpenBTS - at least as long as there are any commercial gsm networks available. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sat Apr 10 21:57:12 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 10 Apr 2010 23:57:12 +0200 Subject: Use OsmocomBB as OpenBTS / airprobe clock generator In-Reply-To: <20100410214745.GB3284@prithivi.gnumonks.org> References: <20100410214745.GB3284@prithivi.gnumonks.org> Message-ID: Hi, The Altera Cyclone on the USRP1 has two internal PLL. Has anybody tried to use those to get a internal 52 MHz clock from an external 13 MHz input ? I've been wondering about that for a while now ... Sylvain From laforge at gnumonks.org Sun Apr 11 05:39:40 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Apr 2010 07:39:40 +0200 Subject: Use OsmocomBB as OpenBTS / airprobe clock generator In-Reply-To: References: <20100410214745.GB3284@prithivi.gnumonks.org> Message-ID: <20100411053940.GG3284@prithivi.gnumonks.org> Hi! On Sat, Apr 10, 2010 at 11:57:12PM +0200, Sylvain Munaut wrote: > The Altera Cyclone on the USRP1 has two internal PLL. oh, great, even better. We were speculating about that for some time and then thought it might be easier to generate the signal externally than to set up the proprietary toolchain fro building a modified version of the FPGA bitstream. > Has anybody tried to use those to get a internal 52 MHz clock from an > external 13 MHz input ? Maybe a good idea to ask that at gnuradio-discuss and the openbts mailing lists. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Sat Apr 10 23:28:27 2010 From: steve at steve-m.de (Steve Markgraf) Date: Sun, 11 Apr 2010 01:28:27 +0200 Subject: Use OsmocomBB as OpenBTS / airprobe clock generator In-Reply-To: <20100410214745.GB3284@prithivi.gnumonks.org> References: <20100410214745.GB3284@prithivi.gnumonks.org> Message-ID: <4BC1099B.8070504@steve-m.de> Hi, interesting idea... Harald Welte wrote: > Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to > multiply it up to the required 52 MHz. However, neither the Openmoko > nor the Compal/Motorola phones expose any of the 3 clock output pads :( Hmm, 3 output pads? I only see DPLLCLK and CLKOUT_DSP, the third one would be CLKX_SPI, but can that one be used for this purpose? I looked at the Motorola W220, which uses the DPLLCLK-pin as TSPACT5 wired through a buffer to GSM900_TX of the antenna switch. see: http://www.steve-m.de/projects/osmocom/w220_dpllclk.jpg The pin on the buffer is quite well accessible, so we could tie it to low (and disable TX with that, but we don't need that anyway, right?) and use VC1B as clock output. Our code already runs on the W220, but we would need a driver for the Si4210 GSM transceiver. Regards, Steve From steve at steve-m.de Sun Apr 11 00:21:19 2010 From: steve at steve-m.de (Steve Markgraf) Date: Sun, 11 Apr 2010 02:21:19 +0200 Subject: Use OsmocomBB as OpenBTS / airprobe clock generator In-Reply-To: <4BC1099B.8070504@steve-m.de> References: <20100410214745.GB3284@prithivi.gnumonks.org> <4BC1099B.8070504@steve-m.de> Message-ID: <4BC115FF.4060209@steve-m.de> Hi once again, Steve Markgraf wrote: > I looked at the Motorola W220, which uses the DPLLCLK-pin as TSPACT5 > wired through a buffer to GSM900_TX of the antenna switch. Exactly the same design on the Motorola C168 by the way, which was manufactured by Chi-Mei, too. Both use the Calypso romloader and have the UART_MODEM wired to the headphone plug, like the Compal phones. But the C168 wasn't sold in Europe as it seems. Regards, Steve From laforge at gnumonks.org Sun Apr 11 05:37:05 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Apr 2010 07:37:05 +0200 Subject: Use OsmocomBB as OpenBTS / airprobe clock generator In-Reply-To: <4BC1099B.8070504@steve-m.de> References: <20100410214745.GB3284@prithivi.gnumonks.org> <4BC1099B.8070504@steve-m.de> Message-ID: <20100411053705.GF3284@prithivi.gnumonks.org> Hi Steve, On Sun, Apr 11, 2010 at 01:28:27AM +0200, Steve Markgraf wrote: > >Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to > >multiply it up to the required 52 MHz. However, neither the Openmoko > >nor the Compal/Motorola phones expose any of the 3 clock output pads :( > > Hmm, 3 output pads? I only see DPLLCLK and CLKOUT_DSP, the third one > would be CLKX_SPI, but can that one be used for this purpose? The third one is MCLK, i.e. the clock that the Calypos PLL feeds into the ARM core. > I looked at the Motorola W220, which uses the DPLLCLK-pin as TSPACT5 > wired through a buffer to GSM900_TX of the antenna switch. > > see: > http://www.steve-m.de/projects/osmocom/w220_dpllclk.jpg > > The pin on the buffer is quite well accessible, so we could tie it > to low (and disable TX with that, but we don't need that anyway, > right?) and use VC1B as clock output. Yes, I agree, this should work just fine. However, using the Altera internal PLL to multiply from 13 to 52 sounds even better! > Our code already runs on the W220, but we would need a driver for > the Si4210 GSM transceiver. That doesn't sound hard. Didn't you say that you have documentation? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Sun Apr 11 15:54:57 2010 From: steve at steve-m.de (Steve Markgraf) Date: Sun, 11 Apr 2010 17:54:57 +0200 Subject: Use OsmocomBB as OpenBTS / airprobe clock generator In-Reply-To: <20100411053705.GF3284@prithivi.gnumonks.org> References: <20100410214745.GB3284@prithivi.gnumonks.org> <4BC1099B.8070504@steve-m.de> <20100411053705.GF3284@prithivi.gnumonks.org> Message-ID: <4BC1F0D1.5010809@steve-m.de> Hi, Harald Welte wrote : > The third one is MCLK, i.e. the clock that the Calypos PLL feeds into > the ARM core. Ah, okay. But this one isn't accessible on all currently known phones anyway. Steve From vogelchr at vogel.cx Sun Apr 11 17:05:28 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 11 Apr 2010 19:05:28 +0200 Subject: Patch: UART initialisation, serial port errors Message-ID: <20100411170527.GA5298@vogel.cx> Hi, I've seen a lot of systematic character swaps on the serial port, especially in the vincinity of 0-bytes. As the XON/XOFF registers are the only thing in the UART that look like they would consider the actual data sent, I've added this initialisation to uart.c This makes the problem go away completely on my C123. To check for it I've added CRCs to the HDLC protocol and checked for bad frames, and also compared them in a (patched) osmocon that just sends random garbate in a special DLCI. The bad frames I observed always looked like this (number in parenthesis define number of omitted bytes, for brevity): <------ good bytes ----------> <-recvd|sent-> <----- identical again ------> d0 e0 00 00..(107)..f7 ce 17 c4 < 0c 00|00 0c > db 70 ba cb..(67)..d8 6d 3a 1f 31 e1 00 00..(47)..38 ca 2f e5 < 0c 00|00 0c > f8 a3 77 5f..(127)..5b 72 ff 4a <-- good -> <--- bad -----> <---- good again -------------> dc e1 00 00 < 0c 00|00 0c > 87 cb 24 83..(178)..2f 69 b3 51 ae e2 00 00..(167)..bd 18 6f a1 < 0c 00|00 0c > 2f 53 d2 b2..(7)..da c7 1b 63 dc e3 00 00..(131)..8e 2c b0 a8 < 0c 00|00 0c > 40 62 56 5f..(43)..f0 3a 47 f7 Formerly I was observing about 10 packets for every 2000 sent (with 192 bytes of payload each). Now, with the added initialisation, I see (as the time of writing this email) 12000 packets with 192 bytes each sent, with 0 bytes missing, corrupted, flipped). Please have a look and tell me if it's helping for you. I'll send the HDLC/CRC patch in another email. Chris -------------- next part -------------- commit 9cac7985ec7384a6584c8846e41c0ddaade8774f Author: Christian Vogel Date: Sun Apr 11 18:47:28 2010 +0200 Additional initialisations for the UART to make the data corruption from the PC to the Phone go away. diff --git a/src/target/firmware/calypso/uart.c b/src/target/firmware/calypso/uart.c index c78ad05..a46fff9 100644 --- a/src/target/firmware/calypso/uart.c +++ b/src/target/firmware/calypso/uart.c @@ -303,6 +303,16 @@ void uart_init(uint8_t uart, uint8_t interrupts) writeb(UART_REG_UIR, 0x00); } #endif + + /* if we don't initialize these, we get strange corruptions in the + received data... :-( */ + uart_reg_write(uart, MDR1, 0x07); /* turn off UART */ + uart_reg_write(uart, XON1, 0x00); /* Xon1/Addr Register */ + uart_reg_write(uart, XON2, 0x00); /* Xon2/Addr Register */ + uart_reg_write(uart, XOFF1, 0x00); /* Xoff1 Register */ + uart_reg_write(uart, XOFF2, 0x00); /* Xoff2 Register */ + uart_reg_write(uart, EFR, 0x00); /* Enhanced Features Register */ + /* select UART mode */ uart_reg_write(uart, MDR1, 0); /* no XON/XOFF flow control, ENHANCED_EN, no auto-RTS/CTS */ From spaar at mirider.augusta.de Sun Apr 11 20:58:53 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sun, 11 Apr 2010 20:58:53 CEST Subject: Patch: UART initialisation, serial port errors Message-ID: <4bc2380e.mirider@mirider.augusta.de> Hello Christian, I had the suspicion that a UART reset in the code is missing, however I could not verify that because I never had those problems with wrong bytes. Out of curiousity, have you tried if just the following line is enough to fix the problems you noticed ? > + uart_reg_write(uart, MDR1, 0x07); /* turn off UART */ This should cause the UART to be reset and I would expect that setting the XON/XOFF characters is not needed as long XON/XOFF handshake is not turned on. Thanks and best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Mon Apr 12 12:52:47 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Apr 2010 14:52:47 +0200 Subject: public project with MTK baseband firmware project Message-ID: <20100412125247.GB19994@prithivi.gnumonks.org> Hi all! In case you're interested, there seems to be a public project on code.google.com that contains the build environment and baseband firmware sdk from mediatek: svn checkout http://mobile-phone-mtk-project.googlecode.com/svn mtk-project Please note that I don't know about the legality of this. However, it is distributed on a public server/service without any kind of authentication... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Apr 12 14:01:29 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Apr 2010 16:01:29 +0200 Subject: public project with MTK baseband firmware project In-Reply-To: <20100412125247.GB19994@prithivi.gnumonks.org> References: <20100412125247.GB19994@prithivi.gnumonks.org> Message-ID: <20100412140129.GE20725@prithivi.gnumonks.org> On Mon, Apr 12, 2010 at 02:52:47PM +0200, Harald Welte wrote: > In case you're interested, there seems to be a public project on > code.google.com that contains the build environment and baseband > firmware sdk from mediatek: ... which gets me to the next question: Does anyone know a phone based on the MT6223 chipset? We'd be looking for a phone that has this chipset, and for which we can find both the phone (ebay, ...) and schematics somewhere... thanks in advance! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bjoern.riemer at fokus.fraunhofer.de Mon Apr 12 15:37:58 2010 From: bjoern.riemer at fokus.fraunhofer.de (Riemer, Bjoern) Date: Mon, 12 Apr 2010 17:37:58 +0200 Subject: public project with MTK baseband firmware project In-Reply-To: <20100412140129.GE20725@prithivi.gnumonks.org> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100412140129.GE20725@prithivi.gnumonks.org> Message-ID: <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C1@EXCHSRV.fokus.fraunhofer.de> Hi, it seems that the nokia express music 5610 (in the forum they say "nokia exper muzic 5610") uses this kind of chipset (mt6226) and from the source the mt6227 is the same(?) and when I search for that I get many results. bjoern -----Urspr?ngliche Nachricht----- Von: baseband-devel-bounces at lists.osmocom.org [mailto:baseband-devel-bounces at lists.osmocom.org] Im Auftrag von Harald Welte Gesendet: Montag, 12. April 2010 16:01 An: baseband-devel at lists.osmocom.org Betreff: Re: public project with MTK baseband firmware project On Mon, Apr 12, 2010 at 02:52:47PM +0200, Harald Welte wrote: > In case you're interested, there seems to be a public project on > code.google.com that contains the build environment and baseband > firmware sdk from mediatek: ... which gets me to the next question: Does anyone know a phone based on the MT6223 chipset? We'd be looking for a phone that has this chipset, and for which we can find both the phone (ebay, ...) and schematics somewhere... thanks in advance! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Mon Apr 12 16:11:51 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 12 Apr 2010 18:11:51 +0200 Subject: public project with MTK baseband firmware project In-Reply-To: <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C1@EXCHSRV.fokus.fraunhofer.de> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100412140129.GE20725@prithivi.gnumonks.org> <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C1@EXCHSRV.fokus.fraunhofer.de> Message-ID: <4BC34647.5080208@steve-m.de> Hi, Riemer, Bjoern wrote: > it seems that the nokia express music 5610 The MTK chipset is used in clones of this phone, the genuine Nokia xpress music 5610 seems to use some custom DBB: http://www.phonescoop.com/phones/fcc_query.php?gc=QTK&pc=RM-279 Regards, Steve From bjoern.riemer at fokus.fraunhofer.de Mon Apr 12 16:16:49 2010 From: bjoern.riemer at fokus.fraunhofer.de (Riemer, Bjoern) Date: Mon, 12 Apr 2010 18:16:49 +0200 Subject: public project with MTK baseband firmware project In-Reply-To: <4BC34647.5080208@steve-m.de> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100412140129.GE20725@prithivi.gnumonks.org> <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C1@EXCHSRV.fokus.fraunhofer.de> <4BC34647.5080208@steve-m.de> Message-ID: <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C4@EXCHSRV.fokus.fraunhofer.de> Ok. I only did a quick search on google.. But this phone uses the mt6223 chipset: "lenovo 688" It is quite ugly with hello kitty design but has a big screen and is available on ebay. Bjoern -----Urspr?ngliche Nachricht----- Von: Steve Markgraf [mailto:steve at steve-m.de] Gesendet: Montag, 12. April 2010 18:12 An: Riemer, Bjoern Cc: Harald Welte; baseband-devel at lists.osmocom.org Betreff: Re: public project with MTK baseband firmware project Hi, Riemer, Bjoern wrote: > it seems that the nokia express music 5610 The MTK chipset is used in clones of this phone, the genuine Nokia xpress music 5610 seems to use some custom DBB: http://www.phonescoop.com/phones/fcc_query.php?gc=QTK&pc=RM-279 Regards, Steve From gentoo.lubomir at googlemail.com Mon Apr 12 16:27:26 2010 From: gentoo.lubomir at googlemail.com (Lubomir Schmidt) Date: Mon, 12 Apr 2010 18:27:26 +0200 Subject: public project with MTK baseband firmware project In-Reply-To: <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C4@EXCHSRV.fokus.fraunhofer.de> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100412140129.GE20725@prithivi.gnumonks.org> <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C1@EXCHSRV.fokus.fraunhofer.de> <4BC34647.5080208@steve-m.de> <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C4@EXCHSRV.fokus.fraunhofer.de> Message-ID: Would be funny to get in the news with "hacking a hello kitty phone" 2010/4/12 Riemer, Bjoern : > Ok. I only did a quick search on google.. > But this phone uses the mt6223 chipset: "lenovo 688" > It is quite ugly with hello kitty design but has a big screen and is available on ebay. > > Bjoern > > -----Urspr?ngliche Nachricht----- > Von: Steve Markgraf [mailto:steve at steve-m.de] > Gesendet: Montag, 12. April 2010 18:12 > An: Riemer, Bjoern > Cc: Harald Welte; baseband-devel at lists.osmocom.org > Betreff: Re: public project with MTK baseband firmware project > > Hi, > > Riemer, Bjoern wrote: > > ?> it seems that the nokia express music 5610 > > The MTK chipset is used in clones of this phone, the genuine Nokia > xpress music 5610 seems to use some custom DBB: > > http://www.phonescoop.com/phones/fcc_query.php?gc=QTK&pc=RM-279 > > Regards, > Steve > > From frepig at gmail.com Mon Apr 12 17:20:24 2010 From: frepig at gmail.com (Wenhui Liu) Date: Tue, 13 Apr 2010 01:20:24 +0800 Subject: public project with MTK baseband firmware project In-Reply-To: References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100412140129.GE20725@prithivi.gnumonks.org> <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C1@EXCHSRV.fokus.fraunhofer.de> <4BC34647.5080208@steve-m.de> <79C0EA6E7AD7CE4A85EDAF482B5456B2024054C4@EXCHSRV.fokus.fraunhofer.de> Message-ID: Hi,all Most phones made in china are using MTK platform.MTK platform is very cheap and highly integrated? You can download more data or tools here: * ftp://study-bbs.com:study-bbs0304 at 220.113.15.15* Directory names and file names are in chinese,but most datasheets are in english. I'll give you some hints for understanding these chinese words. At the home directory of this ftp account,it may looks like this: / PADS2007?????????? //A video tutorial of a PCB design software max //unknown(maybe related to WinCE) ?????? //unknown ??-????.txt //the same as "readme.txt" ??????? //something about SCM ??001???? //plese entering this directory!MTK related! A MTK develop board ??2440 //A PDA develop board(No GSM support,only wifi) /??001???? directory may looks like: 0.?????? //product introduction(in chinese) 1.??? //develop tools 2.??? //source code 3.C????????? //development documentation in c,datasheet (MTK platform),Maybe usefull 4.?????? //hardware information?about an develop board,not the MTK platform? 5.????? //other document 6.?????? //user contributed documents 7.?? //others(maybe have nothing to do with this project) huayu0001_??PDA????????????.txt //readme(in chinese) huayu0002_??????.txt //changelog(in chinese) huayu0003??????.pdf //faqs(in chinese) huayu506_C?????????????????.txt //faqs for c program(in chinese) huayu507_java???????????????.txt //faqs for java program(in chinese) readme.txt //readme(like an advertisement) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at sharism.cc Tue Apr 13 12:40:39 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Tue, 13 Apr 2010 12:40:39 +0000 Subject: public project with MTK baseband firmware project In-Reply-To: <20100412125247.GB19994@prithivi.gnumonks.org> References: <20100412125247.GB19994@prithivi.gnumonks.org> Message-ID: <20100413124039.GA12383@devel.wolf> Harald, I will try to support the MTK fact and phone finding effort a bit. Since I am currently in Shenzhen I walked down to the street and bought 3 books with MTK schematics. The stuff is probably online already somewhere but I will try to find phones that have matching model numbers to the ones we have schematics for. Those 3 books will be scanned and I will put them up on a server as PDF files. Maybe I go buy another set of books tomorrow and mail them to you in Berlin, just in case (they sell for the price of paper here, ca. 2.50 USD per copy. The data in them is essentially in the public domain in China, many 'publishing houses' (=copy shops) publishing them). At first glance, in the schematics books I bought today I saw the following 6223/6225 phones: --- MT6225: CECT Y200 CECT C3000 (I found a CECT C3100 for only 20 USD, not sure how it differs from C3000) HanTai HT5858 ZhenHua Z898 ZhenHua K888+ (note: many other brands make phones named "K888") (newer ZhenHua seem to be using 6226, would that also work?) BoDao H580 --- MT6223: SanKe K38 From laforge at gnumonks.org Tue Apr 13 15:26:20 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Apr 2010 17:26:20 +0200 Subject: public project with MTK baseband firmware project In-Reply-To: <20100413124039.GA12383@devel.wolf> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100413124039.GA12383@devel.wolf> Message-ID: <20100413152620.GB28773@prithivi.gnumonks.org> Hi Wolfgang, On Tue, Apr 13, 2010 at 12:40:39PM +0000, Wolfgang Spraul wrote: > I will try to support the MTK fact and phone finding effort a bit. thanks a lot for your feedback and input. > Since I am currently in Shenzhen I walked down to the street and bought > 3 books with MTK schematics. The stuff is probably online already somewhere > but I will try to find phones that have matching model numbers to the > ones we have schematics for. You can find the MTK reference schematics easily online - but not the various actual products that Chinese manufacturers build based on them. So those books are probably a really good idea. > Next steps for me: Scan the schematics stuff and put it online. Find some > 6223/6225 based phones that are cheap & suitable for hacking, i.e. ideally > with some nice test points or JTAG. yes, JTAG would be incredibly cool. I really don't understand why the study-bbs.com P1302 and P1300 are sold as development platform and then don't provide JTAG access. The same company even sells ARM JTAG adapters :/ > Other common MTK chips are 6205, 6217, 6218, 6219, 6226, 6228. Yes, I'm aware of them, they all seem to be more or less the same.. but since we have seen leaked versions of the 6223 and 6225 SDK, we should start with them to have a 'known good' setup. > One word of caution - the above lists, and documentation we start digging > up, may give a false impression of predictability. In reality the brand > names and model numbers are a total mess in China. Typos everywhere. All > sorts of things are printed on cases & boxes, chips are changed without > anybody noticing or caring. There are endless smaller Chinese brands making > phones with 6223 or 6225 chips, but I think it will be very hard to use > them as a stable source, to get phones with the same chips over time. So > I think it's better to focus on the somewhat bigger Chinese brands as > listed above. I completely agree. Thanks again, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From frepig at gmail.com Wed Apr 14 03:54:21 2010 From: frepig at gmail.com (Wenhui Liu) Date: Wed, 14 Apr 2010 11:54:21 +0800 Subject: public project with MTK baseband firmware project In-Reply-To: <20100413152620.GB28773@prithivi.gnumonks.org> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100413124039.GA12383@devel.wolf> <20100413152620.GB28773@prithivi.gnumonks.org> Message-ID: hi,harald as you mentioned above,these develop boards have no jtag.because of they are just use for user application develop,not for baseband.i'm sorry for that!maybe we can find something usefull from the datasheet. this mail is send from my phone,and my input method doesn't support uppercases :) 2010/4/13, Harald Welte : > Hi Wolfgang, > > On Tue, Apr 13, 2010 at 12:40:39PM +0000, Wolfgang Spraul wrote: > >> I will try to support the MTK fact and phone finding effort a bit. > > thanks a lot for your feedback and input. > >> Since I am currently in Shenzhen I walked down to the street and bought >> 3 books with MTK schematics. The stuff is probably online already >> somewhere >> but I will try to find phones that have matching model numbers to the >> ones we have schematics for. > > You can find the MTK reference schematics easily online - but not the > various actual products that Chinese manufacturers build based on them. > So those books are probably a really good idea. > >> Next steps for me: Scan the schematics stuff and put it online. Find some >> 6223/6225 based phones that are cheap & suitable for hacking, i.e. ideally >> with some nice test points or JTAG. > > yes, JTAG would be incredibly cool. I really don't understand why the > study-bbs.com P1302 and P1300 are sold as development platform and then > don't provide JTAG access. The same company even sells ARM JTAG > adapters :/ > >> Other common MTK chips are 6205, 6217, 6218, 6219, 6226, 6228. > > Yes, I'm aware of them, they all seem to be more or less the same.. but > since we have seen leaked versions of the 6223 and 6225 SDK, we should > start with them to have a 'known good' setup. > >> One word of caution - the above lists, and documentation we start digging >> up, may give a false impression of predictability. In reality the brand >> names and model numbers are a total mess in China. Typos everywhere. All >> sorts of things are printed on cases & boxes, chips are changed without >> anybody noticing or caring. There are endless smaller Chinese brands >> making >> phones with 6223 or 6225 chips, but I think it will be very hard to use >> them as a stable source, to get phones with the same chips over time. So >> I think it's better to focus on the somewhat bigger Chinese brands as >> listed above. > > I completely agree. > > Thanks again, > Harald > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -- ????????? Regards, Wenhui Liu Department of Computer Science,Nachang University From laforge at gnumonks.org Wed Apr 14 07:36:04 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Apr 2010 09:36:04 +0200 Subject: public project with MTK baseband firmware project In-Reply-To: References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100413124039.GA12383@devel.wolf> <20100413152620.GB28773@prithivi.gnumonks.org> Message-ID: <20100414073604.GK28773@prithivi.gnumonks.org> Hi Wenhui Liu, On Wed, Apr 14, 2010 at 11:54:21AM +0800, Wenhui Liu wrote: > as you mentioned above,these develop boards have no jtag.because of > they are just use for user application develop,not for baseband.i'm > sorry for that! Well, the P1300 and P1302 are based on MT6225, a single-processor baseband design. The vendor provides a version of the MTK SDK exactly for the purpose of adding custom code to the baseband processor of those units. And JTAG is very useful for any kind of development. Even if you do not touch the GSM stack and only do application development, it is still useful for those developers to be able to trace through their code... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From wolfgang at sharism.cc Mon Apr 19 07:21:40 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Mon, 19 Apr 2010 07:21:40 +0000 Subject: public project with MTK baseband firmware project In-Reply-To: <20100413152620.GB28773@prithivi.gnumonks.org> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100413124039.GA12383@devel.wolf> <20100413152620.GB28773@prithivi.gnumonks.org> Message-ID: <20100419072140.GA2947@devel.wolf> Harald, On Tue, Apr 13, 2010 at 05:26:20PM +0200, Harald Welte wrote: > You can find the MTK reference schematics easily online - but not the > various actual products that Chinese manufacturers build based on them. > So those books are probably a really good idea. oh well, your suspicion was correct. The schematics I could find were all MTK reference schematics, not referring to specific phone models. The reason seems to be that there is only a small market for MTK phone repairs, most repair shops focus on phones that cost 150 USD and more. The typical MTK phone costs 20-80 USD so even in China not much efforts are made to repair them. The scans I have are 300 dpi, some details are not visible. I will do this in better quality once I find more valuable data. http://downloads.qi-hardware.com/hardware/hacking/phones/mtk-schematics-1.pdf http://downloads.qi-hardware.com/hardware/hacking/phones/mtk-schematics-2.pdf http://downloads.qi-hardware.com/hardware/hacking/phones/mtk-schematics-3.pdf (I doubt any of this is new compared to what we already have on the other servers pointed out, but I didn't check what is there yet...) I went ahead and bought 5 different MTK phones: 1) QQ phone (looks like a penguin), ca. 60 USD, MT6225A, MT6188C, MT6318A, MT6601T 2) DaXian X968, ca. 35 USD, MT6223DA, SuperPix SP5369, can't identify (0943 11B, S, LRS18C8G) 3) JinPeng S3566, ca. 35 USD, MT6225A, MT6139BN, MT6318A, MT6601T 4) JinPeng S6811, ca 35 USD, MT6223DA, MT6139BN, SKY77518-21 5) CECT C3100, ca 20 USD, MT6223CA, MT6139BN, RDA6212+ The standard set of 5 test points I seem to find on all MTK phones are PWRKEY, RX, TX, GND and VBAT. Beyond that test points are rare. The CECT C3100 had a few small ones right next to the CPU (but under a soldered shielding case). Might be something interesting but not sure yet. I will continue to investigate the C3100, Wolfgang From laforge at gnumonks.org Tue Apr 13 16:49:47 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Apr 2010 18:49:47 +0200 Subject: Request for review: GSM phone hardware introduction Message-ID: <20100413164946.GC28773@prithivi.gnumonks.org> Hi! I've written an introductory text on GSM mobile phone architecture, and before officially posting/announcing it, I thought I'd invite the members of this list to do some review and give feedback! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm_phone-anatomy-v0.1.pdf Type: application/pdf Size: 174318 bytes Desc: not available URL: From emersonv6 at gmx.com Tue Apr 13 19:00:20 2010 From: emersonv6 at gmx.com (emersonv6) Date: Tue, 13 Apr 2010 21:00:20 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <20100413164946.GC28773@prithivi.gnumonks.org> References: <20100413164946.GC28773@prithivi.gnumonks.org> Message-ID: <4BC4BF44.8070109@gmx.com> Hi, First, congratulations for the project, it got my attention from the first day I heard about it. At the moment I'm trying to get one of the C123s so as soon as possible I'd like to start contributing in some area. I'm totally agree with the full document but found some minor gramatical mistakes: page 7, chapter 5 Synchronization and Clocking, first paragraph: - ha - means meant page 9, section 6.3 Dual-SIM and Triple-SIM phones, last paragraph: - baesband page 10, paragraph 7: - kidn keep the great work, emersonv6 Harald Welte escribi?: > Hi! > > I've written an introductory text on GSM mobile phone architecture, > and before officially posting/announcing it, I thought I'd invite > the members of this list to do some review and give feedback! > From laforge at gnumonks.org Tue Apr 13 19:07:08 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Apr 2010 21:07:08 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <4BC4A560.1010406@appelbaum.net> References: <20100413164946.GC28773@prithivi.gnumonks.org> <4BC4A560.1010406@appelbaum.net> Message-ID: <20100413190708.GF28773@prithivi.gnumonks.org> Hi Jake (and others), On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote: > > I've written an introductory text on GSM mobile phone architecture, > > and before officially posting/announcing it, I thought I'd invite > > the members of this list to do some review and give feedback! > > Do you have the latex available? It's hard to edit and send a diff of a > pdf... see attachment. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm_phone-anatomy-v0.1.tex Type: text/x-tex Size: 21099 bytes Desc: not available URL: From itsme at xs4all.nl Wed Apr 14 10:34:36 2010 From: itsme at xs4all.nl (willem) Date: Wed, 14 Apr 2010 12:34:36 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <20100413190708.GF28773@prithivi.gnumonks.org> References: <20100413164946.GC28773@prithivi.gnumonks.org> <4BC4A560.1010406@appelbaum.net> <20100413190708.GF28773@prithivi.gnumonks.org> Message-ID: <4BC59A3C.8090504@xs4all.nl> On 2010-04-13 21:07:08, Harald Welte wrote: > Hi Jake (and others), > > On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote: > >>> I've written an introductory text on GSM mobile phone architecture, >>> and before officially posting/announcing it, I thought I'd invite >>> the members of this list to do some review and give feedback! >>> >> Do you have the latex available? It's hard to edit and send a diff of a >> pdf... >> did you omit qualcomm in your list of baseband manufacturers intentionaly? because it produces mostly cdma and 3g chipsets, and not gsm? i have several additions to your document: == in the list in subsection{MCU peripherals} \item Audio routing, selecting how audio is routed in the phone, between AP, BB, carspeaker,headset, mediaspeaker, phonespeaker and microphone == addition to \subsection{The Digital Baseband (DBB)} The baseband MCU usually runs a realtime operating system(RTOS), like nucleus, vxworks, or l4k. == a subsection in section{Miscellaneous Topics} \subsection{Security features} There are several things that need protection against tampering in a gsm phone, the Ki ( the secret key which identifies the subscriber to the network ), the IMEI ( the hardware id of the phone ), and various restrictions set by your cellular provider (commonly known as 'the simlock'). The Ki is stored in the SIM, and is never handled by the baseband software directly, it cannot be read from the SIM. The IMEI on the other hand is just an arbitrary string stored in flash, usually obfuscated in some way, to make it more difficult to change. But there is no special hardware ( like a SIM ) involved in protecting it. willem From laforge at gnumonks.org Wed Apr 14 21:14:42 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Apr 2010 23:14:42 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <4BC59A3C.8090504@xs4all.nl> References: <20100413164946.GC28773@prithivi.gnumonks.org> <4BC4A560.1010406@appelbaum.net> <20100413190708.GF28773@prithivi.gnumonks.org> <4BC59A3C.8090504@xs4all.nl> Message-ID: <20100414211441.GD7381@prithivi.gnumonks.org> On Wed, Apr 14, 2010 at 12:34:36PM +0200, willem wrote: > On 2010-04-13 21:07:08, Harald Welte wrote: > > Hi Jake (and others), > > > > On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote: > > > >>> I've written an introductory text on GSM mobile phone architecture, > >>> and before officially posting/announcing it, I thought I'd invite > >>> the members of this list to do some review and give feedback! > >>> > >> Do you have the latex available? It's hard to edit and send a diff of a > >> pdf... > >> > > did you omit qualcomm in your list of baseband manufacturers > intentionaly? because it produces mostly cdma and 3g chipsets, and not gsm? yes, that's why I ignored Qualcomm. > i have several additions to your document: thanks! > == in the list in subsection{MCU peripherals} > \item Audio routing, selecting how audio is routed in the phone, between > AP, BB, carspeaker,headset, mediaspeaker, phonespeaker and microphone good point - though a lot of complexity is only required in the smartphone case. > == addition to \subsection{The Digital Baseband (DBB)} > > The baseband MCU usually runs a realtime operating system(RTOS), like > nucleus, vxworks, or l4k. i've added it, but to the software architecture part. > == a subsection in section{Miscellaneous Topics} thanks. I've rewritten this entirely and added a number of security related sub-sections to the document. Please find the new version v0.3 attached. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm_phone-anatomy-v0.3.pdf Type: application/pdf Size: 190644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm_phone-anatomy-v0.3.tex Type: text/x-tex Size: 22437 bytes Desc: not available URL: From osmocom at ngolde.de Thu Apr 15 10:22:54 2010 From: osmocom at ngolde.de (Nico Golde) Date: Thu, 15 Apr 2010 12:22:54 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <20100413190708.GF28773@prithivi.gnumonks.org> References: <20100413164946.GC28773@prithivi.gnumonks.org> <4BC4A560.1010406@appelbaum.net> <20100413190708.GF28773@prithivi.gnumonks.org> Message-ID: <20100415102254.GA21658@pool.math.tu-berlin.de> Hi, * Harald Welte [2010-04-15 11:21]: > On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote: > > > I've written an introductory text on GSM mobile phone architecture, > > > and before officially posting/announcing it, I thought I'd invite > > > the members of this list to do some review and give feedback! > > > > Do you have the latex available? It's hard to edit and send a diff of a > > pdf... > > see attachment. Very interesting read, thanks a lot! Attached is a very small patch. Cheers Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm_phone-anatomy-v0.1.tex.patch Type: text/x-diff Size: 1881 bytes Desc: not available URL: From laforge at gnumonks.org Thu Apr 15 12:46:07 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 15 Apr 2010 14:46:07 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <20100415102254.GA21658@pool.math.tu-berlin.de> References: <20100413164946.GC28773@prithivi.gnumonks.org> <4BC4A560.1010406@appelbaum.net> <20100413190708.GF28773@prithivi.gnumonks.org> <20100415102254.GA21658@pool.math.tu-berlin.de> Message-ID: <20100415124607.GD18200@prithivi.gnumonks.org> On Thu, Apr 15, 2010 at 12:22:54PM +0200, Nico Golde wrote: > Hi, > * Harald Welte [2010-04-15 11:21]: > > On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote: > > > > I've written an introductory text on GSM mobile phone architecture, > > > > and before officially posting/announcing it, I thought I'd invite > > > > the members of this list to do some review and give feedback! > > > > > > Do you have the latex available? It's hard to edit and send a diff of a > > > pdf... > > > > see attachment. > > Very interesting read, thanks a lot! > Attached is a very small patch. thanks, I've fixed those typos. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From fgiff at fsfe.org Tue Apr 13 20:46:00 2010 From: fgiff at fsfe.org (fgiff) Date: Tue, 13 Apr 2010 21:46:00 +0100 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <20100413164946.GC28773@prithivi.gnumonks.org> References: <20100413164946.GC28773@prithivi.gnumonks.org> Message-ID: <4BC4D808.7040208@fsfe.org> Hi, You've done a good and useful overview of the AP+BP architecture, but I think you need to rethink describing this as something that differentiates a smartphone from a feature phone. I agree that there's no industry definition of feature phone vs. smartphone, but I don't agree with your suggestion that a feature phone has just the BP and a smartphone a BP and AP. For me, a feature phone is voice calls plus some features (music, camera etc.) and smartphone is voice calls and installable native software (i.e. not J2ME). It's a marketing difference more than anything. Regards, Frans On 13/04/10 17:49, Harald Welte wrote: > Hi! > > I've written an introductory text on GSM mobile phone architecture, > and before officially posting/announcing it, I thought I'd invite > the members of this list to do some review and give feedback! > > From hopsingk at gmail.com Sat Apr 17 07:17:25 2010 From: hopsingk at gmail.com (Hopsing K) Date: Sat, 17 Apr 2010 09:17:25 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <20100413164946.GC28773@prithivi.gnumonks.org> References: <20100413164946.GC28773@prithivi.gnumonks.org> Message-ID: Hi, I'd like to put suggest something: There is a gpl opensource soc framework called grlib at gaisler.com. It has a sparcv8 cpu at its heart and supports many configurations/boards, spartan, virtex, cyclon and actel devices (also asic targets..). All the peripherals to build up a capable platform are there, s/sd/ddr memctrl, ethernet etc. Also a nonintrusive debug support unit with ethernet link etc. All around an AMBA bus. Now I wonder: The ursp2 is supplied in verilog at gnuradio, the analog expansion boards can be ordered at etus or build self, the analog boards dont seem to be that complex... So why not add the usrp2 verilog parts as amba-peripherals to the grlib framework and then run the whole system on a fpga? I'd be able to help here also... -- Greetings Konrad 2010/4/13 Harald Welte > Hi! > > I've written an introductory text on GSM mobile phone architecture, > and before officially posting/announcing it, I thought I'd invite > the members of this list to do some review and give feedback! > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Apr 17 08:01:16 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 17 Apr 2010 10:01:16 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: References: <20100413164946.GC28773@prithivi.gnumonks.org> Message-ID: <20100417080115.GV18200@prithivi.gnumonks.org> At the moment we're not looking for building something entirely new again. We have our hands full implementing a layer1/layer2/layer3 stack that is currently targeted for the Ti Calypso DBB. The next step after completion is to port this to other DBB, e.g. the Mediatek 622x series. This seems more promising to us rather than redesigning the hardware from scratch. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From hopsingk at gmail.com Sat Apr 17 17:52:00 2010 From: hopsingk at gmail.com (Hopsing K) Date: Sat, 17 Apr 2010 19:52:00 +0200 Subject: Request for review: GSM phone hardware introduction In-Reply-To: <20100417080115.GV18200@prithivi.gnumonks.org> References: <20100413164946.GC28773@prithivi.gnumonks.org> <20100417080115.GV18200@prithivi.gnumonks.org> Message-ID: Ok, I understand. I actually bought a c123 motorola phone also and am trying to get familiar with it. 2010/4/17 Harald Welte > At the moment we're not looking for building something entirely new > again. > > We have our hands full implementing a layer1/layer2/layer3 stack that is > currently targeted for the Ti Calypso DBB. The next step after > completion is to port this to other DBB, e.g. the Mediatek 622x series. > > This seems more promising to us rather than redesigning the hardware > from scratch. > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogelchr at vogel.cx Tue Apr 13 17:49:16 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Tue, 13 Apr 2010 19:49:16 +0200 Subject: Patch: Add CRC16 to libosmocore Message-ID: <20100413174915.GA9210@vogel.cx> Hi everyone, prom is using the crc16 as implemented in the Linux Kernel for his bootloader work, and I'm planning to add an optional crc16 check for sercomm. To have crc16 easily accessible in baseband, this commit adds it to libosmocore. Chris -------------- next part -------------- commit 05a00c91d99dbe615e3879cca5efe26ac14889f3 Author: Christian Vogel Date: Tue Apr 13 19:45:19 2010 +0200 Add crc16 (from Linux Kernel lib/crc16.c) to libosmocore. diff --git a/src/shared/libosmocore/include/osmocore/Makefile.am b/src/shared/libosmocore/include/osmocore/Makefile.am index 1c3a33f..a16c2d0 100644 --- a/src/shared/libosmocore/include/osmocore/Makefile.am +++ b/src/shared/libosmocore/include/osmocore/Makefile.am @@ -1,7 +1,7 @@ osmocore_HEADERS = signal.h linuxlist.h timer.h select.h msgb.h \ tlv.h bitvec.h comp128.h statistics.h gsm_utils.h utils.h \ gsmtap.h write_queue.h rsl.h gsm48.h rxlev_stat.h mncc.h \ - gsm48_ie.h logging.h + gsm48_ie.h logging.h crc16.h if ENABLE_TALLOC osmocore_HEADERS += talloc.h diff --git a/src/shared/libosmocore/include/osmocore/crc16.h b/src/shared/libosmocore/include/osmocore/crc16.h new file mode 100644 index 0000000..9369e81 --- /dev/null +++ b/src/shared/libosmocore/include/osmocore/crc16.h @@ -0,0 +1,30 @@ +/* + * crc16.h - CRC-16 routine --- From Linux Kernel V2.6 include/linux/crc16.h + * + * Implements the standard CRC-16: + * Width 16 + * Poly 0x8005 (x^16 + x^15 + x^2 + 1) + * Init 0 + * + * Copyright (c) 2005 Ben Gardner + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + +#ifndef __OSMOCORE_CRC16_H +#define __OSMOCORE_CRC16_H + +#include + +extern uint16_t const osmocore_crc16_table[256]; + +extern uint16_t osmocore_crc16(uint16_t crc, const uint8_t *buffer, int len); + +static inline uint16_t osmocore_crc16_byte(uint16_t crc, const uint8_t data) +{ + return (crc >> 8) ^ osmocore_crc16_table[(crc ^ data) & 0xff]; +} + +#endif /* __OSMOCORE_CRC16_H */ + diff --git a/src/shared/libosmocore/src/Makefile.am b/src/shared/libosmocore/src/Makefile.am index 1697807..c7cbb7d 100644 --- a/src/shared/libosmocore/src/Makefile.am +++ b/src/shared/libosmocore/src/Makefile.am @@ -10,7 +10,7 @@ lib_LTLIBRARIES = libosmocore.la libosmocore_la_SOURCES = timer.c select.c signal.c msgb.c rxlev_stat.c \ tlv_parser.c bitvec.c comp128.c gsm_utils.c statistics.c \ write_queue.c utils.c rsl.c gsm48.c gsm48_ie.c \ - logging.c + logging.c crc16.c if ENABLE_TALLOC libosmocore_la_SOURCES += talloc.c diff --git a/src/shared/libosmocore/src/crc16.c b/src/shared/libosmocore/src/crc16.c new file mode 100644 index 0000000..172c1ed --- /dev/null +++ b/src/shared/libosmocore/src/crc16.c @@ -0,0 +1,60 @@ +/* + * crc16.c -- From Linux Kernel V2.6 / lib/crc16.c + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + +#include + +/** CRC table for the CRC-16. The poly is 0x8005 (x^16 + x^15 + x^2 + 1) */ +uint16_t const osmocore_crc16_table[256] = { + 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, + 0xC601, 0x06C0, 0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440, + 0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1, 0xCE81, 0x0E40, + 0x0A00, 0xCAC1, 0xCB81, 0x0B40, 0xC901, 0x09C0, 0x0880, 0xC841, + 0xD801, 0x18C0, 0x1980, 0xD941, 0x1B00, 0xDBC1, 0xDA81, 0x1A40, + 0x1E00, 0xDEC1, 0xDF81, 0x1F40, 0xDD01, 0x1DC0, 0x1C80, 0xDC41, + 0x1400, 0xD4C1, 0xD581, 0x1540, 0xD701, 0x17C0, 0x1680, 0xD641, + 0xD201, 0x12C0, 0x1380, 0xD341, 0x1100, 0xD1C1, 0xD081, 0x1040, + 0xF001, 0x30C0, 0x3180, 0xF141, 0x3300, 0xF3C1, 0xF281, 0x3240, + 0x3600, 0xF6C1, 0xF781, 0x3740, 0xF501, 0x35C0, 0x3480, 0xF441, + 0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41, + 0xFA01, 0x3AC0, 0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840, + 0x2800, 0xE8C1, 0xE981, 0x2940, 0xEB01, 0x2BC0, 0x2A80, 0xEA41, + 0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1, 0xEC81, 0x2C40, + 0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640, + 0x2200, 0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041, + 0xA001, 0x60C0, 0x6180, 0xA141, 0x6300, 0xA3C1, 0xA281, 0x6240, + 0x6600, 0xA6C1, 0xA781, 0x6740, 0xA501, 0x65C0, 0x6480, 0xA441, + 0x6C00, 0xACC1, 0xAD81, 0x6D40, 0xAF01, 0x6FC0, 0x6E80, 0xAE41, + 0xAA01, 0x6AC0, 0x6B80, 0xAB41, 0x6900, 0xA9C1, 0xA881, 0x6840, + 0x7800, 0xB8C1, 0xB981, 0x7940, 0xBB01, 0x7BC0, 0x7A80, 0xBA41, + 0xBE01, 0x7EC0, 0x7F80, 0xBF41, 0x7D00, 0xBDC1, 0xBC81, 0x7C40, + 0xB401, 0x74C0, 0x7580, 0xB541, 0x7700, 0xB7C1, 0xB681, 0x7640, + 0x7200, 0xB2C1, 0xB381, 0x7340, 0xB101, 0x71C0, 0x7080, 0xB041, + 0x5000, 0x90C1, 0x9181, 0x5140, 0x9301, 0x53C0, 0x5280, 0x9241, + 0x9601, 0x56C0, 0x5780, 0x9741, 0x5500, 0x95C1, 0x9481, 0x5440, + 0x9C01, 0x5CC0, 0x5D80, 0x9D41, 0x5F00, 0x9FC1, 0x9E81, 0x5E40, + 0x5A00, 0x9AC1, 0x9B81, 0x5B40, 0x9901, 0x59C0, 0x5880, 0x9841, + 0x8801, 0x48C0, 0x4980, 0x8941, 0x4B00, 0x8BC1, 0x8A81, 0x4A40, + 0x4E00, 0x8EC1, 0x8F81, 0x4F40, 0x8D01, 0x4DC0, 0x4C80, 0x8C41, + 0x4400, 0x84C1, 0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641, + 0x8201, 0x42C0, 0x4380, 0x8341, 0x4100, 0x81C1, 0x8081, 0x4040 +}; + +/** + * crc16 - compute the CRC-16 for the data buffer + * @crc: previous CRC value + * @buffer: data pointer + * @len: number of bytes in the buffer + * + * Returns the updated CRC value. + */ +uint16_t osmocore_crc16(uint16_t crc, uint8_t const *buffer, int len) +{ + while (len--) + crc = osmocore_crc16_byte(crc, *buffer++); + return crc; +} + From vogelchr at vogel.cx Tue Apr 13 19:55:44 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Tue, 13 Apr 2010 21:55:44 +0200 Subject: Patch: Add CRC16 to sercomm In-Reply-To: <20100413174915.GA9210@vogel.cx> References: <20100413174915.GA9210@vogel.cx> Message-ID: <20100413195544.GB31425@vogel.cx> Hi everyone, this patch adds a optional CRC16 checksum to sercomm. To compile it needs the CRC16 in libosmocore. A bit in the control-byte of the HDLC frame signals if the received frame contains a trailing CRC, if that's the case but the CRC is not ok, the frame is dropped. Note: For debugging purposes a frame on the ECHO DLCI is not dropped! We might want to check for corruption in the data so we are interested in bad frames! To send frames with CRC on a specific DLCI use sercomm_tx_set_crc16(int dlci,int onoff); to turn it on. By default CRC16 on Tx is enabled for the ECHO and CONSOLE DLCIs. Chris -------------- next part -------------- commit 7a49f811b1ed121c35c05673abdbd6ea64ed2c06 Author: Christian Vogel Date: Tue Apr 13 21:34:42 2010 +0200 Add CRC16 to HDLC frames. diff --git a/src/target/firmware/comm/sercomm.c b/src/target/firmware/comm/sercomm.c index b6bda50..b952a9c 100644 --- a/src/target/firmware/comm/sercomm.c +++ b/src/target/firmware/comm/sercomm.c @@ -25,6 +25,7 @@ #include #include +#include #ifdef HOST_BUILD #define SERCOMM_RX_MSG_SIZE 2048 @@ -63,6 +64,7 @@ static struct { struct llist_head dlci_queues[_SC_DLCI_MAX]; struct msgb *msg; enum rx_state state; + uint16_t crc16_dlci_mask; /* set 1<data+2,msg->len-2); + msgb_put_u16(msg,crc16_data); // put MSB, then LSB + hdr[1] |= HDLC_C_CRC16_BIT; + } + /* This functiion can be called from any context: FIQ, IRQ * and supervisor context. Proper locking is important! */ local_irq_save(flags); @@ -212,6 +233,42 @@ static void dispatch_rx_msg(uint8_t dlci, struct msgb *msg) sercomm.rx.dlci_handler[dlci](dlci, msg); } +/* check if crc16 of message msg is valid: If it is, strip + the two crc16 bytes and return 0, if it's invalid return 1 */ +static int sercomm_chk_strip_crc16(struct msgb *msg) +{ + uint16_t crc16_msg,crc16_data; + if(msg->len < 2) // too short to contain a crc16 + return 1; + + msg->len -= 2; /* this does the opposite of msgb_put(msg,2) */ + msg->tail -= 2; /* to trim the crc in the last two bytes */ + + crc16_data = osmocore_crc16(0,msg->data,msg->len); + crc16_msg = (msg->data[msg->len]<<8) + msg->data[msg->len+1]; + +#ifdef HOST_BUILD + if(crc16_msg != crc16_data){ + fprintf(stderr,"\r\033[0;31mBAD CRC\033[0m"); + fprintf(stderr," on dlci %d: recv %04x calc %04x\n", + sercomm.rx.dlci,crc16_msg,crc16_data); + } +#endif + + if(crc16_msg != crc16_data) // crc error + return 1; + + return 0; +} + +void +sercomm_tx_set_crc16(int dlci,int onoff){ + if(onoff) + sercomm.tx.crc16_dlci_mask |= (1< Hi, this patch adds a new DLCI, Numbered 11, which just echoes whatever it recveices on the mobile back to the PC. It is very useful for debugging serial port problems. Chris -------------- next part -------------- commit 787a9f109aa5f9d9e089c179ac02651035a158bc Author: Christian Vogel Date: Tue Apr 13 21:18:32 2010 +0200 Added a ECHO DLCI that just sends all the data back from the mobile to the PC. diff --git a/src/target/firmware/comm/sercomm.c b/src/target/firmware/comm/sercomm.c index 505de70..b6bda50 100644 --- a/src/target/firmware/comm/sercomm.c +++ b/src/target/firmware/comm/sercomm.c @@ -85,6 +85,11 @@ void sercomm_init(void) sercomm.rx.msg = NULL; sercomm.initialized = 1; + +#ifndef HOST_BUILD + /* Enable sending back ECHO only on the target! */ + sercomm_register_rx_cb(SC_DLCI_ECHO,&sercomm_sendmsg); +#endif } int sercomm_initialized(void) diff --git a/src/target/firmware/include/comm/sercomm.h b/src/target/firmware/include/comm/sercomm.h index 45a1e99..c8963a3 100644 --- a/src/target/firmware/include/comm/sercomm.h +++ b/src/target/firmware/include/comm/sercomm.h @@ -21,6 +21,7 @@ enum sercomm_dlci { SC_DLCI_L1A_L23 = 5, SC_DLCI_LOADER = 9, SC_DLCI_CONSOLE = 10, + SC_DLCI_ECHO = 11, _SC_DLCI_MAX }; From laforge at gnumonks.org Mon Apr 19 14:35:28 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Apr 2010 16:35:28 +0200 Subject: How to grow and scale the project? Message-ID: <20100419143528.GW18200@prithivi.gnumonks.org> Hi! As you can see, there is not really that much progress throughout the last 2 weeks or so. Dieter and myself were the only two who actually looked at how to driver the DSP, TPU and RF hardware, write the drivers for it and the existing layer1 code. Now we're both busy with other (paid) work, and the project almost seems stuck. I would like to see this change. I'm quite sure there are some other folks on this list who would be interested in diving in those lower layer bits of the system. However, I also understand there is not all too much that can be done without running your own non-hopping BTS (as we don't do frequency hopping at the moment). So a working OpenBTS, OpenBSC setup or something like a CMD55 or Racal 6103 are a precondition. Nonetheless, a number of people on this list have access to those devices. I'd like to encourage some other people to also look at this and remove the dependence on Dieter and myself in that area. Furthermore, members of the IRC channel have certainly noticed the growing interest in a potential port to the Mediatek chipset based devicees. Mediatek is churning out more than 95 million chipsets every quarter, so there is plenty of phones around. The data sheets, reference schematics and other training materials can easily be found on a lot of chinese developer websites - as is the Mediatek SDK. However, the critical layer1 and DSP API part is only provided in object code, and the documentation does not document it. Still I believe it is feasible. So if you want to stay out of the GSM part, feel like the Calypso is too boring for you: Why not work on getting a minimal custom software image for the MT622x running, including bootloader support, keypad/touchscreen and graphics output? If that is done by the wider community, the so-called experts can focus on looking at the GSM side of things once they have time. Even on the Calypso there are many tasks that still need to be finished, including battery charging, power management, file system, SIM Card API, etc. If you know somebody who understands C development for microcontrollers and wants to help building the worlds first Free Software GSM baseband chipset software, please motivate them to join. We can really need every helping hand we get. Happy hacking, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From squalyl at gmail.com Mon Apr 19 15:02:15 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Mon, 19 Apr 2010 17:02:15 +0200 Subject: How to grow and scale the project? In-Reply-To: <20100419143528.GW18200@prithivi.gnumonks.org> References: <20100419143528.GW18200@prithivi.gnumonks.org> Message-ID: Hi! just to let the list know that the sim project is not dead, but just like you I have other (paid) works to complete before. I'm working on it with feedback and testing from Dieter. We're not so far from having something functional for osmocombb. I should have posted an update before, and of course I'll announce when it's complete^W openly publishable. Let me say that anyone with javacard skills, or willing to develop such skills, is welcome. my code is not in oscombb git yet, but is still available to anyone asking from svn. Knowning that we're building the world's first free software GSM stack is a good motivation for me, and I'm glad to help where I can. Regards Sebastien On Mon, Apr 19, 2010 at 4:35 PM, Harald Welte wrote: > Hi! > > As you can see, there is not really that much progress throughout the last > 2 > weeks or so. Dieter and myself were the only two who actually looked at > how > to driver the DSP, TPU and RF hardware, write the drivers for it and the > existing layer1 code. Now we're both busy with other (paid) work, and > the project almost seems stuck. > > I would like to see this change. I'm quite sure there are some other folks > on this list who would be interested in diving in those lower layer bits > of the system. However, I also understand there is not all too much that > can be done without running your own non-hopping BTS (as we don't do > frequency > hopping at the moment). So a working OpenBTS, OpenBSC setup or something > like a CMD55 or Racal 6103 are a precondition. > > Nonetheless, a number of people on this list have access to those devices. > > I'd like to encourage some other people to also look at this and remove the > dependence on Dieter and myself in that area. > > > Furthermore, members of the IRC channel have certainly noticed the growing > interest in a potential port to the Mediatek chipset based devicees. > Mediatek > is churning out more than 95 million chipsets every quarter, so there is > plenty > of phones around. > > The data sheets, reference schematics and other training materials can > easily > be found on a lot of chinese developer websites - as is the Mediatek SDK. > However, the critical layer1 and DSP API part is only provided in object > code, > and the documentation does not document it. > > Still I believe it is feasible. So if you want to stay out of the GSM > part, > feel like the Calypso is too boring for you: Why not work on getting a > minimal > custom software image for the MT622x running, including bootloader support, > keypad/touchscreen and graphics output? If that is done by the wider > community, the so-called experts can focus on looking at the GSM side of > things > once they have time. > > Even on the Calypso there are many tasks that still need to be finished, > including battery charging, power management, file system, SIM Card API, > etc. > > If you know somebody who understands C development for microcontrollers and > wants to help building the worlds first Free Software GSM baseband chipset > software, please motivate them to join. We can really need every helping > hand > we get. > > Happy hacking, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thegrugq at gmail.com Mon Apr 19 15:40:20 2010 From: thegrugq at gmail.com (the grugq) Date: Mon, 19 Apr 2010 22:40:20 +0700 Subject: How to grow and scale the project? In-Reply-To: <20100419143528.GW18200@prithivi.gnumonks.org> References: <20100419143528.GW18200@prithivi.gnumonks.org> Message-ID: <514F55CD-4C90-4FAD-B93B-572000FEFE5C@gmail.com> On a related note, this might be useful for someone looking at an MTK bootloader. I don't believe this code is in most of the leaked SDKs, but I've see it on pudn.net... http://rapidshare.com/files/377689884/mtk-bootloader.tar.gz.html There might be a couple other versions floating around as well. I can check for them if people are interested. > Still I believe it is feasible. So if you want to stay out of the GSM part, > feel like the Calypso is too boring for you: Why not work on getting a minimal > custom software image for the MT622x running, including bootloader support, I don't know anything about microcontroller development, so I can't be much help there I'm afraid. From bjoern.riemer at fokus.fraunhofer.de Tue Apr 20 08:26:52 2010 From: bjoern.riemer at fokus.fraunhofer.de (Riemer, Bjoern) Date: Tue, 20 Apr 2010 10:26:52 +0200 Subject: AW: How to grow and scale the project? In-Reply-To: <514F55CD-4C90-4FAD-B93B-572000FEFE5C@gmail.com> References: <20100419143528.GW18200@prithivi.gnumonks.org> <514F55CD-4C90-4FAD-B93B-572000FEFE5C@gmail.com> Message-ID: <79C0EA6E7AD7CE4A85EDAF482B5456B202405501@EXCHSRV.fokus.fraunhofer.de> i think the code tot he bootloader is here.. http://code.google.com/p/mobile-phone-mtk-project/source/browse/V01_VER/?r=33#V01_VER/08BW0916MP_NEP_V5_gsm_MMI/bootloader/src -----Urspr?ngliche Nachricht----- Von: baseband-devel-bounces at lists.osmocom.org [mailto:baseband-devel-bounces at lists.osmocom.org] Im Auftrag von the grugq Gesendet: Montag, 19. April 2010 17:40 An: baseband-devel at lists.osmocom.org Betreff: Re: How to grow and scale the project? On a related note, this might be useful for someone looking at an MTK bootloader. I don't believe this code is in most of the leaked SDKs, but I've see it on pudn.net... http://rapidshare.com/files/377689884/mtk-bootloader.tar.gz.html There might be a couple other versions floating around as well. I can check for them if people are interested. > Still I believe it is feasible. So if you want to stay out of the GSM part, > feel like the Calypso is too boring for you: Why not work on getting a minimal > custom software image for the MT622x running, including bootloader support, I don't know anything about microcontroller development, so I can't be much help there I'm afraid. From laforge at gnumonks.org Tue Apr 20 09:32:29 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 20 Apr 2010 11:32:29 +0200 Subject: Who would attend a developer room / meeting at FrOSCon ? Message-ID: <20100420093229.GS18200@prithivi.gnumonks.org> Hi! I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/) which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin from August 21/22 this year. Before sending a response, I would like to inquire whom of you would actually have any intention of visiting this conference and spending time in the developer room to work on OpenBSC or OsmocomBB ? I think the idea is great to meet some of you guys [again], not only at the annual CCC congress in winter. But there is little point for me to go there if there is no interest from the wider project community. Please provide your feedback ASAP. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keytwho at hotmail.com Tue Apr 20 13:47:47 2010 From: keytwho at hotmail.com (None None) Date: Tue, 20 Apr 2010 13:47:47 +0000 Subject: osmocon In-Reply-To: <20100420093229.GS18200@prithivi.gnumonks.org> References: <20100420093229.GS18200@prithivi.gnumonks.org> Message-ID: For some reason, using a FTDI cable or not, I get that when I run the osmocon procedure with a c123 connected using a serial cable either to a FTDI module or directly using ttyS0. Someone has an idea ? regards. root at key2-desktop:/usr/src/osmocom-bb/src/host/osmocon# ./osmocon -p /dev/ttyUSB0 -m c123 ../../target/firmware/board/compal_e88/hello_world.ramload.bin got 1 bytes from modem, data looks like: 00 got 2 bytes from modem, data looks like: f7 00 got 4 bytes from modem, data looks like: 72 00 00 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 4d got 1 bytes from modem, data looks like: a3 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 root at key2-desktop:/usr/src/osmocom-bb/src/host/osmocon# ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/hello_world.ramload.bin got 1 bytes from modem, data looks like: 00 got 2 bytes from modem, data looks like: f7 00 got 3 bytes from modem, data looks like: 72 82 bf got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 _________________________________________________________________ Consultez gratuitement vos emails Orange, Gmail, Free, ... directement dans HOTMAIL ! http://www.windowslive.fr/hotmail/agregation/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From keytwho at hotmail.com Tue Apr 20 14:05:12 2010 From: keytwho at hotmail.com (None None) Date: Tue, 20 Apr 2010 14:05:12 +0000 Subject: osmocon In-Reply-To: References: <20100420093229.GS18200@prithivi.gnumonks.org>, Message-ID: ok found out First info: do NOT use the http://www.dealextreme.com/details.dx/sku.14664 this cable does NOT convert the rs232 to TLL 3.3v signal. I had to use a converter in order to get it to work. From: keytwho at hotmail.com To: baseband-devel at lists.osmocom.org Subject: osmocon Date: Tue, 20 Apr 2010 13:47:47 +0000 For some reason, using a FTDI cable or not, I get that when I run the osmocon procedure with a c123 connected using a serial cable either to a FTDI module or directly using ttyS0. Someone has an idea ? regards. root at key2-desktop:/usr/src/osmocom-bb/src/host/osmocon# ./osmocon -p /dev/ttyUSB0 -m c123 ../../target/firmware/board/compal_e88/hello_world.ramload.bin got 1 bytes from modem, data looks like: 00 got 2 bytes from modem, data looks like: f7 00 got 4 bytes from modem, data looks like: 72 00 00 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 4d got 1 bytes from modem, data looks like: a3 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 root at key2-desktop:/usr/src/osmocom-bb/src/host/osmocon# ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/hello_world.ramload.bin got 1 bytes from modem, data looks like: 00 got 2 bytes from modem, data looks like: f7 00 got 3 bytes from modem, data looks like: 72 82 bf got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: 00 T?l?charger en toute s?curit? sur Internet ? La solution avec Internet Explorer 8 _________________________________________________________________ Consultez vos emails Orange, Gmail, Yahoo!, Free ... directement depuis HOTMAIL ! http://www.windowslive.fr/hotmail/agregation/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Apr 21 07:19:50 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 21 Apr 2010 09:19:50 +0200 Subject: Receiving on TS=1 ? Message-ID: Hi, I've hacked something together to quickly test non-combined CCCH. However, I've hit a problem when trying to receive anything on another timeslot than 0. The TX side seems to work fine as the BTS can see my location update request and answers with a reject, but on the MS side, I never see the reject and wireshark only shows invalid incohrent data on the RX. The frames for SDCCH/8 show really nothing valid (looks like random bytes), things like 09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36 ... while the frames for the associated SAACH show at least something gsm-like : 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b but that's not quite a SI5/6 ... To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 * 156.25) when I'm in dedicated channel mode by chaning the 'start' in l1s_tx_win_ctrl / l1s_rx_win_ctrl Is there something else that should be done ? Cheers, Sylvain From 246tnt at gmail.com Wed Apr 21 07:27:23 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 21 Apr 2010 09:27:23 +0200 Subject: Receiving on TS=1 ? In-Reply-To: References: Message-ID: Hum, ... I just made a fool out of myself :) > The frames for SDCCH/8 show really nothing valid (looks like random > bytes), things like > > 09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 That actually looks like SI5 > 09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36 and that kinda looks like SI6 So maybe the problem might be else where ... time to look into LAPDm ... Sylvain From 246tnt at gmail.com Wed Apr 21 20:16:35 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 21 Apr 2010 22:16:35 +0200 Subject: Receiving on TS=1 ? In-Reply-To: References: Message-ID: Some more infos ... 1) I changed the mframe_schedule a bit so that when changing task, we deactivate the first then wait a little before activating the next one. I think it would have been possible that previous MF task scheduled something that would conflict with the new MF task ... 2) I replaced the SDCCH8_0 task with a custom one : static const struct mframe_sched_item mf_rx_all_nb[] = { { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 0 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 4 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 8 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 12 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 16 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 20 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 24 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 28 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 32, .flags = MF_F_SACCH }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 36, .flags = MF_F_SACCH }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 40, .flags = MF_F_SACCH }, { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 44, .flags = MF_F_SACCH }, { .sched_set = NULL } }; This basically is RX only and receives all SDCCH and SAACH on the timeslot. When I do this, I see the good data on SAACH and SDCCH correcponding to subchannel 0. (everything else is garbage). But if I try a custom task that just RX subchannel 0 : static const struct mframe_sched_item mf_rx_all_nb[] = { { .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 0 }, { .sched_set = NB_QUAD_FH_DL, .modulo = 2*51, .frame_nr = 32, .flags = MF_F_SACCH }, { .sched_set = NULL } }; Then, it doesn't work, I don't see the SI5/6 messages on SAACH. Cheers, Sylvain From emersonv6 at gmx.com Wed Apr 21 22:55:28 2010 From: emersonv6 at gmx.com (emersonv6) Date: Thu, 22 Apr 2010 00:55:28 +0200 Subject: plabs prj Message-ID: <4BCF8260.1060409@gmx.com> Hi, plabs project seems to be removed from sf.net, did somebody mirror it or something? regards, emerson From laforge at gnumonks.org Thu Apr 22 05:36:42 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Apr 2010 07:36:42 +0200 Subject: plabs prj In-Reply-To: <4BCF8260.1060409@gmx.com> References: <4BCF8260.1060409@gmx.com> Message-ID: <20100422053642.GD24811@prithivi.gnumonks.org> On Thu, Apr 22, 2010 at 12:55:28AM +0200, emersonv6 wrote: > plabs project seems to be removed from sf.net, Yes. I asked sf.net and all they indicated: "It was removed because of a violation". No indication what was violated (Trademark, Patents, Copyright) nor who actually requested its removal. Quite surprising, considering the project was up for more than 5 years :( -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From emersonv6 at gmx.com Thu Apr 22 10:37:13 2010 From: emersonv6 at gmx.com (emersonv6) Date: Thu, 22 Apr 2010 12:37:13 +0200 Subject: backlight reg? Message-ID: <4BD026D9.7080102@gmx.com> Hi, I was reading the bl_mode_pwl function at backlight.c and found that PWL_CTRL is being written at 0xfffe8002 (0xfffe8000 + 2) which doesn't map to any known reg. According to the second datasheet PWL_CTRL (Control Register (PWL_CTRL_REG) (Read / Write)) is located at 0xfffe8001. maybe i'm wrong? regards, emerson. From steve at steve-m.de Thu Apr 22 10:44:14 2010 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 22 Apr 2010 12:44:14 +0200 Subject: backlight reg? In-Reply-To: <4BD026D9.7080102@gmx.com> References: <4BD026D9.7080102@gmx.com> Message-ID: <4BD0287E.7050801@steve-m.de> Hi, emersonv6 wrote: > I was reading the bl_mode_pwl function at backlight.c and found > that PWL_CTRL is being written at 0xfffe8002 (0xfffe8000 + 2) > which doesn't map to any known reg. According to the second datasheet > PWL_CTRL (Control Register (PWL_CTRL_REG) (Read / Write)) is located at > 0xfffe8001. Yes, you are right, but this has already been fixed by prom in his branch: http://bb.osmocom.org/trac/changeset/796f6aef383ec6802a4d659bf179419ef9b39e13 The changes haven't been merged to master yet, though. Regards, Steve From emersonv6 at gmx.com Thu Apr 22 17:16:37 2010 From: emersonv6 at gmx.com (emersonv6) Date: Thu, 22 Apr 2010 19:16:37 +0200 Subject: PWT and PWL relation Message-ID: <4BD08475.6000504@gmx.com> Hi, I've playing for a while with the buzzer & PWT registers and I'm able to hear 'sound' according to the frequencies supported. The thing I can't not understand well is the relation between the PWT (pulse width tones) and the PWL (pulse width light), if exists: A) After loading some frequency into the PWT, set the volume and hear the it, if I change PWT to BU in the ASIC_CONF_REG, backlight intensity changes and sound stops. B) With LT output selected in the ASIC_CONF_REG instead of PWL, changes over the PWT registers produce nothing. From laforge at gnumonks.org Sat Apr 24 12:03:11 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 24 Apr 2010 14:03:11 +0200 Subject: Off-by-one errors in Tx timing Message-ID: <20100424120311.GQ24811@prithivi.gnumonks.org> Hi all, as this has been a quite weird bug so far, and Sylvain now seems to have run into some related problems when trying to make a SDCCH8 on TS1 work, I'll elaborate a bit more on it. Before commit 0e9d250407f589cff312adc6c9e2c83f6af37de5, what happened was as follows: 1) The time between the TDMA interrupt happening and starting to execute l1_sync() and actually being able to configure the TPU window and tell the DSP what to do was too short for performing the scheduled work in the very same TDMA frame. 2) As a result, the actions that we thought were performed in the same TDMA were actually performed one TDMA later. Somehow we must have had another off-by-one error and thus the two errors compensated themselves in most cases, particularly for Rx 3) When trying to send, we hand a MAC BLOCK of 23 bytes to the DSP, after which the DSP has to do the FEC, Fire CRC, burst spreading, etc - before being able to generate the bits for the furst burst. Those bits then get sent over the TSP to the ABB (into its burst buffer), from where they are sent based on TPU signals. So what happened is that the data of the first burst was not in the burst buffer yet, and the TPU signals triggered sending the last burst of the previous MAC block, rather than the first burst of the current. This is why Dieter added the > tpu_enq_at(5000 - 10); /* TPU_CLOCK_RANGE - EPSILON_SYNC */ to l1s_tx_win_ctrl(), thereby delaying the TPU signal generation by one TDMA frame. At that time, the DSP has by long finished writing the new burst bits in to the ABB burst buffer, and we can transmit the correct burst data. I personally believe it would be better to simply move the TDMA interrupt a bit more ahead. Rather than occurring immediately before TS0, we could set SYNCHRO in a way that it occurs at a defined point in time still quite a bit into TS7. In this case we hopefully have enough time for the DSP to be able to transmit in TS0, making the timing sequence easier to understand. Hope that helps to explain... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sun Apr 25 15:16:48 2010 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Sun, 25 Apr 2010 15:16:48 +0000 Subject: Off-by-one errors in Tx timing In-Reply-To: <20100424120311.GQ24811@prithivi.gnumonks.org> Message-ID: <0016e6d971022b1a430485112643@google.com> > 1) The time between the TDMA interrupt happening and starting to execute > l1_sync() and actually being able to configure the TPU window and tell the > DSP what to do was too short for performing the scheduled work in the > very same TDMA frame. I think it's never executed in the same TDMA frame. My understanding is : - The frame interrupt is triggered (let's call this instant t=0 qbits) - At this moment the interrupt handler is called and we : . setup some command for the db in the API DB page. (0 or 1) . put a scenario in the TPU memory. . enable the tpu to generate a frame interrupt to the DSP at the _next_ frame. ( t = 5000 qbits ) . enable tpu_en so the TPU start the execution of the scenario we just put in. - It's only at the next frame (t = 5000) that the DSP will actually read what we asked it to do. . for RX, it will just setup a buffer to receive the data . for TX, it will do fire/crc/... and send the data to the ABB buffer So our TPU window _must_ be during that next frame ... * For RX it always worked for TS=0 because in l1s_rx_win_ctrl we put the first command AT(DSP_SETUP_TIME - 100) ... which when you do the modulo 5000 is somewhere around 4944. So when we start executing the TPU scenario in the interrupt handler, that first AT command will force to wait almost an entire frame and the rx window will be properly placed in the next frame. * When I tried to open the RX window at TS=1 by just offsetting the commands of l1s_rx_win_ctrl by 625 qbits, that changed the first AT command to something around ~ 550, so when we set tpu_en, that time was possibly not yet passsed and the RX window was executed 1 TDMA frame early. I could work around that by forcing a AT(0) as the first command if the start > 0. (but that's a quick hack to test my theory) * For TX, we need the tpu_enq_at(5000 - 10) all the time because TX is always 3 TS after RX, the time of the first AT command was always not yet passed before we enabled tpu_en so we executed the TX window 1 timeslot early ... Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Apr 25 18:03:31 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 25 Apr 2010 20:03:31 +0200 Subject: Off-by-one errors in Tx timing In-Reply-To: <0016e6d971022b1a430485112643@google.com> References: <20100424120311.GQ24811@prithivi.gnumonks.org> <0016e6d971022b1a430485112643@google.com> Message-ID: <20100425180331.GE24624@prithivi.gnumonks.org> Hi Sylvain, On Sun, Apr 25, 2010 at 03:16:48PM +0000, 246tnt at gmail.com wrote: > >1) The time between the TDMA interrupt happening and starting to execute > >l1_sync() and actually being able to configure the TPU window and tell the > >DSP what to do was too short for performing the scheduled work in the > >very same TDMA frame. > > I think it's never executed in the same TDMA frame. > > My understanding is : [...] Yes, you were completely right. I was confused before. I agree with everything you have said. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Sun Apr 25 21:32:38 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sun, 25 Apr 2010 21:32:38 CEST Subject: Off-by-one errors in Tx timing Message-ID: <4bd4b4f7.mirider@mirider.augusta.de> Hello Sylvain, On Sun, 25 Apr 2010 15:16:48 +0000, 246tnt at gmail.com wrote: > > * For RX it always worked for TS=0 because in l1s_rx_win_ctrl we put the > first command AT(DSP_SETUP_TIME - 100) ... which when you do the modulo > 5000 is somewhere around 4944. So when we start executing the TPU scenario > in the interrupt handler, that first AT command will force to wait almost > an entire frame and the rx window will be properly placed in the next frame. To be true, I don't know where the "- 100" in the recent versions come from. In earlier version the actual AT time was 54 (DSP_SETUP_TIME - TSP_DELAY - 6). This is about 50 us. However we had the same situation (actual processing happens in the next frame) because the time to execute the code after the interrupt occured till the TPU was enabled took a little bit more than those 50 us. Probably the code has changed in recent versions so that it tooks less than those 50 us and "- 100" is needed. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 246tnt at gmail.com Sun Apr 25 20:34:43 2010 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Sun, 25 Apr 2010 20:34:43 +0000 Subject: Off-by-one errors in Tx timing In-Reply-To: <4bd4b4f7.mirider@mirider.augusta.de> Message-ID: <0016e65b43e227b8d404851597ea@google.com> Hi Dieter, > To be true, I don't know where the "- 100" in the recent versions come > from. In earlier version the actual AT time was 54 (DSP_SETUP_TIME - > TSP_DELAY - 6). When you look deeper into the call, there is the PLL setup that is done even earlier, to ensure that it's finished by that 'start' time. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From spaar at mirider.augusta.de Sun Apr 25 22:58:16 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sun, 25 Apr 2010 22:58:16 CEST Subject: Off-by-one errors in Tx timing Message-ID: <4bd4c908.mirider@mirider.augusta.de> Hello Sylvain, > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > When you look deeper into the call, there is the PLL setup that is done > even earlier, to ensure that it's finished by that 'start' time. The earlier versions I refer to did no yet switch RX/TX for each burst, they used to switch after four burst were received/transmitted. In those versions only the ABB windows was used with the TPU, however we had the same situation because the code till enabling the TPU took longer than the "AT" value. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From Andreas.Eversberg at versatel.de Mon Apr 26 12:52:39 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 26 Apr 2010 14:52:39 +0200 Subject: Layer 3 status Message-ID: hi, i like to give a short update about the current layer 3 development. everything compiles, but is not tested and debugged yet. it is divided into five processes: - radio ressource this process is partly complete. it implements functions to establish radio ressource connection. especially handover and release/abort is not implemented, but will follow soon. most things here depend on services of the radio part. as the radio part gets more and more functionality, the radio ressource can be more and more completed. - mobility management this process is complete. it also implements the location update process. - call control this process is complete. the MNCC interface of the call control is almost identical to the openbsc. therefore i would suggest to merge both "mncc.h" header files and put them into osmocore. currently there is a minimal application in mnccms.c which rejects any call. (any MS must at least do this.) later, a small telephone application could be used. - cell selection this process is complete. it does not do any measurements on the radio part for cell (re-)selection. what it does is taking the results and storing them in a structure. the structure is then used for selecting a cell. it also controls the frequency used by the radio part. - PLMN selection this process is complete. but the manual cell selection requires a user interface, which does not yet exist. it uses informations from cell selection process to select available networks. the term 'complete' refers only to basic call/data service. there is no VGCS, VBS, multislot, GPRS, SoSLA support. since there is no interface to the SIM card process (reading of data / storing data), there is just a comment in the source code whenever data has to be transferred from/to the SIM. also some special things, like NCC or cell priorization may be missing. i will start testing it tonight and hope to get results soon. regards, andreas From 246tnt at gmail.com Mon Apr 26 13:22:11 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 26 Apr 2010 15:22:11 +0200 Subject: Layer 3 status In-Reply-To: References: Message-ID: Hi, > i will start testing it tonight and hope to get results soon. Here's a few bug reports Sorry, there are no 'proper' fix or patches for them, I just worked around them with ugly hacks see if I could get up to LOCATION UPDATE REQUEST, then it was kinda late ... I hope just pointing them out will help you a bit anyway. 1) Typo in src/host/layer23/src/gsm322.c -> gsm322_a_sel_first_plmn /* if no PLMN in list */ - if (plmn_first) { + if (!plmn_first) { 2) BCCH message don't have the same header. See in src/host/layer23/src/gsm48_rr.c in gsm48_rr_unit_data_ind struct gsm48_hdr *gh = msgb_l3(msg); But in BCCH some message don't have this header and have a 'L2 pseudo length' field ... 3) You do a msgb_free on messages in , but the layer 1 will actually have freed those message already. See src/host/layer23/src/main.c in layer2_read(struct bsc_fd *fd) l1ctl_recv((struct osmocom_ms *) fd->data, msg); msgb_free(msg); // <====== Sylvain From Andreas.Eversberg at versatel.de Mon Apr 26 14:26:06 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 26 Apr 2010 16:26:06 +0200 Subject: AW: Layer 3 status Message-ID: hi, 1) thanx for that info. i can see that you tried running it... 2) i have not checked it. i hope that msg->l3h points to l2 pseudo header. 3) before fixing that, i need to have an issue solved: two approaches to free a message, if it passes a layer border? a) the sending layer frees the message after calling the other layer. b) the receiving layer frees the message. i prefer the second approach, because the message can be queued by the receiving layer without duplicating it. but if i read lapdm.c, i cannot figure out what approach is ment to be used: - rslms_recvmsg() frees message if discriminator is not known, otherwhise it forward it to rslms_rx_rll(). - rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does not free it when RLL message type is unknown. this issue must be solved soon, i think. thanx for looking at it, andreas -----Urspr?ngliche Nachricht----- Von: Sylvain Munaut [mailto:246tnt at gmail.com] Gesendet: Montag, 26. April 2010 15:22 An: Andreas.Eversberg Cc: baseband-devel at lists.osmocom.org Betreff: Re: Layer 3 status Hi, > i will start testing it tonight and hope to get results soon. Here's a few bug reports Sorry, there are no 'proper' fix or patches for them, I just worked around them with ugly hacks see if I could get up to LOCATION UPDATE REQUEST, then it was kinda late ... I hope just pointing them out will help you a bit anyway. 1) Typo in src/host/layer23/src/gsm322.c -> gsm322_a_sel_first_plmn /* if no PLMN in list */ - if (plmn_first) { + if (!plmn_first) { 2) BCCH message don't have the same header. See in src/host/layer23/src/gsm48_rr.c in gsm48_rr_unit_data_ind struct gsm48_hdr *gh = msgb_l3(msg); But in BCCH some message don't have this header and have a 'L2 pseudo length' field ... 3) You do a msgb_free on messages in , but the layer 1 will actually have freed those message already. See src/host/layer23/src/main.c in layer2_read(struct bsc_fd *fd) l1ctl_recv((struct osmocom_ms *) fd->data, msg); msgb_free(msg); // <====== Sylvain From Andreas.Eversberg at versatel.de Mon Apr 26 15:06:05 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 26 Apr 2010 17:06:05 +0200 Subject: AW: Layer 3 status Message-ID: > - rslms_recvmsg() frees message if discriminator is not known, otherwhise it forward it to rslms_rx_rll(). > - rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does not free it when RLL message type is unknown. it seems that the message is freed by the receiving layer (or function), but i cannot understand why layer2_read() in main.c does it after calling l1ctl_recv. From Andreas.Eversberg at versatel.de Tue Apr 27 07:31:46 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 27 Apr 2010 09:31:46 +0200 Subject: not tuning to another bcch Message-ID: hi, while debugging my layer3 code and testing bcch_scan, i got the following problem: the fist 'tuning' message L1CTL_NEW_CCCH_REQ to layer 1 works, system informations are received. subsequently tuning to another channel does not give any rx data. any idea? andreas Mit freundlichen Gr??en, .-. /'v'\ (/ \) ------------------------------------------------------------------"-"- |_| i.A. Andreas Eversberg Network Operations / 2nd Level Data - KC Internet Versatel Nord GmbH Nordstr. 2 D-24937 Flensburg Fon: +49-461-9099749 | Fax: +49-461-909960749 andreas.eversberg at versatel.de@versatel.de | www.versatel.de Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL Gesch?ftsf?hrer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Apr 27 15:20:43 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 27 Apr 2010 17:20:43 +0200 Subject: not tuning to another bcch In-Reply-To: References: Message-ID: <20100427152043.GF24624@prithivi.gnumonks.org> Hi Andreas. On Tue, Apr 27, 2010 at 09:31:46AM +0200, Andreas.Eversberg wrote: > the fist 'tuning' message L1CTL_NEW_CCCH_REQ to layer 1 works, system > informations are received. subsequently tuning to another channel does not > give any rx data. any idea? This is a known problem, but despite working from morning through night I really don't have any time to fix the various layer1 issues at the moment, sorry. In fact, there are some fundamental changes/cleanups required, and I've already literally spent days in coming up with an architecture that seems to make sense to me :/ I know it must be frustrating for you, but it seems our schedules didn't match very well. Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Wed Apr 28 09:02:29 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 28 Apr 2010 11:02:29 +0200 Subject: AW: not tuning to another bcch Message-ID: > This is a known problem, but despite working from morning through night I > really don't have any time to fix the various layer1 issues at the moment, > sorry. In fact, there are some fundamental changes/cleanups required, and > I've already literally spent days in coming up with an architecture that seems > to make sense to me :/ > I know it must be frustrating for you, but it seems our schedules didn't match > very well. hi harald, i am currently testing the process of cell selection. when i limit the number of cells down to 1, i can test some parts of the process. don't worry about frustrating me. i can wait until these issues are solved. until then, there is so much more for me todo: - system information parsing test - testing location update procedure - working on incomplete radio ressource process - maybe start working on some layer 4 application (lcr interface) regards, andreas From laforge at gnumonks.org Wed Apr 28 18:26:07 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 28 Apr 2010 20:26:07 +0200 Subject: TODO list / Next project goals Message-ID: <20100428182607.GD19657@prithivi.gnumonks.org> Hi! I think we corrently have the following TODO list. GSM Layer 1: * implement transmit power control for transmit * implement SDCCH/8 on TS1-7 (Sylvain) * implement frequency hopping * proper split between synchronous and asynchronous part of L1 (Harald) * TCH/F support (Dieter, after L3 RR/MM/CC is working) * A5/1 and A5/2 encryption support GSM Layer 2: * implement a real layer2 that deserves the name (full LAPDm implementation) * properly encapsulate / abstract the L1 "MPH" primitives so L3 doesnt call L1 directly anymore GSM Layer 3: * test most of the code that Andreas has written (depends on L1 / L2) Misc: * SIM card driver + ISO7816 FS API * Battery charger driver * UI framework * minimal journalling flash file system * decide which RTOS kernel we want to use (Harald) * fully support a working firmware build for the openmoko gta01/gta02 GSM modem using calypso romloader For people who don't feel like they can take any of this work, there is some other work, regarding the mid-term port to our next target platform: * implement host utility for the medaitek MT622x romloader serial protocol * try to get a minimal hello world codebase to run on the MT622x * write hardware drivers for UART, PMU, I2C, SPI, ... of the MT622x Regards, Harald. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Wed Apr 28 20:38:00 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 28 Apr 2010 20:38:00 CEST Subject: TODO list / Next project goals Message-ID: <4bd89ca8.mirider@mirider.augusta.de> Hello Harald, On Wed, 28 Apr 2010 20:26:07 +0200, "Harald Welte" wrote: > > GSM Layer 1: > * implement transmit power control for transmit > * implement SDCCH/8 on TS1-7 (Sylvain) > * implement frequency hopping > * proper split between synchronous and asynchronous part of L1 (Harald) > * TCH/F support (Dieter, after L3 RR/MM/CC is working) > * A5/1 and A5/2 encryption support I can take care of * implement frequency hopping * A5/1 and A5/2 encryption support in addition to * TCH/F support because this would fit together (just different setting on the GSM testset to do frequency hopping or encryption with a TCH). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From openbsc at mail.tsaitgaist.info Wed Apr 28 18:52:52 2010 From: openbsc at mail.tsaitgaist.info (Kevin Redon) Date: Wed, 28 Apr 2010 20:52:52 +0200 Subject: TODO list / Next project goals In-Reply-To: <20100428182607.GD19657@prithivi.gnumonks.org> References: <20100428182607.GD19657@prithivi.gnumonks.org> Message-ID: <1272480772.4629.202.camel@dennou> Hi, For the SIM reader, how about using SAP (SIM Access Profile) ? Originally it's a bluetooth profile http://www.bluetooth.com/Specification%20Documents/SAP_SPEC_V11.pdf. It's not as powerful as PC/SC, because SIM in mind instead of SmartCard, but it makes it much simpler and lighter (could be integrated in futur ROM). The specs are small. There should then be a SAP server for the card reader, and osmocom would have a SAP client. This architecture would provide the possibility the access the SIM card also from a client on a computer, but also have a SIM server on the computer for osmocom (using standard PC/SC card reader). Greetings, Kevin On Wed, 2010-04-28 at 20:26 +0200, Harald Welte wrote: > Hi! > > I think we corrently have the following TODO list. > > GSM Layer 1: > * implement transmit power control for transmit > * implement SDCCH/8 on TS1-7 (Sylvain) > * implement frequency hopping > * proper split between synchronous and asynchronous part of L1 (Harald) > * TCH/F support (Dieter, after L3 RR/MM/CC is working) > * A5/1 and A5/2 encryption support > > GSM Layer 2: > * implement a real layer2 that deserves the name (full LAPDm implementation) > * properly encapsulate / abstract the L1 "MPH" primitives so L3 doesnt > call L1 directly anymore > > GSM Layer 3: > * test most of the code that Andreas has written (depends on L1 / L2) > > Misc: > * SIM card driver + ISO7816 FS API > * Battery charger driver > * UI framework > * minimal journalling flash file system > * decide which RTOS kernel we want to use (Harald) > * fully support a working firmware build for the openmoko gta01/gta02 GSM modem > using calypso romloader > > For people who don't feel like they can take any of this work, there is some > other work, regarding the mid-term port to our next target platform: > * implement host utility for the medaitek MT622x romloader serial protocol > * try to get a minimal hello world codebase to run on the MT622x > * write hardware drivers for UART, PMU, I2C, SPI, ... of the MT622x > > Regards, > Harald. From peter at stuge.se Wed Apr 28 20:50:00 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 28 Apr 2010 22:50:00 +0200 Subject: TODO list / Next project goals In-Reply-To: <1272480772.4629.202.camel@dennou> References: <20100428182607.GD19657@prithivi.gnumonks.org> <1272480772.4629.202.camel@dennou> Message-ID: <20100428205000.29306.qmail@stuge.se> Kevin Redon wrote: > This architecture would provide the possibility the access the SIM > card also from a client on a computer, but also have a SIM server > on the computer for osmocom (using standard PC/SC card reader). And to use a SIM in another physical phone. //Peter From nibbler at ccc.de Wed Apr 28 20:52:29 2010 From: nibbler at ccc.de (nibbler) Date: Wed, 28 Apr 2010 22:52:29 +0200 Subject: TODO list / Next project goals In-Reply-To: <1272480772.4629.202.camel@dennou> References: <20100428182607.GD19657@prithivi.gnumonks.org> <1272480772.4629.202.camel@dennou> Message-ID: <20100428225229.6953d8a0@minime> On Wed, 28 Apr 2010 20:52:52 +0200 Kevin Redon wrote: > For the SIM reader, how about using SAP (SIM Access Profile) ? good call. IMHO SAP just has the right level of abstraction and would ease the usage of SIMs as they could remain in a SAP supporting phone. Many current phones support SAP so they can be used e.g. in car-phones. An openmoko accepting remote SIMs via SAP of course would be uber-cool. thumbs up. nibbler From allenpais777 at yahoo.com Thu Apr 29 05:41:39 2010 From: allenpais777 at yahoo.com (Allen Pais) Date: Wed, 28 Apr 2010 22:41:39 -0700 (PDT) Subject: TODO list / Next project goals In-Reply-To: <20100428182607.GD19657@prithivi.gnumonks.org> Message-ID: <213267.45573.qm@web35308.mail.mud.yahoo.com> Hi, ? I'd like to work on this pointer. ???? * decide which RTOS kernel we want to use (Harald) - Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Fri Apr 30 07:39:07 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Fri, 30 Apr 2010 09:39:07 +0200 Subject: disable comitting of files Message-ID: hi, i like to change some tracked files without committing them. when i do "git commit -a", every change is comitted. sometimes i like to play with layer1 code or even change Makefile.inc, but i don't want to reset my changes before committing. any idea how to create a list of omitted files? andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Fri Apr 30 07:51:40 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 30 Apr 2010 09:51:40 +0200 Subject: disable comitting of files In-Reply-To: References: Message-ID: Hi, > i like to change some tracked files without committing them. when i do "git > commit -a", every change is comitted. > > sometimes i like to play with layer1 code or even change Makefile.inc, but i > don't want to reset my changes before committing. > > any idea how to create a list?of omitted files? look at the .gitignore file. Since it's checked in, you need to add it to itself as well ... Also, you might want to look at 'git citool' to cherry pick what you want to commit (down to chunk/line selection). There is also a '-i' interactive commit mode. Also, in either 'git citool' or by adding the '-v' option to commit, you can view the changes you're about to commit and I always find that useful to look at it for a few seconds before committing. Cheers, Sylvain From peter at stuge.se Fri Apr 30 07:52:45 2010 From: peter at stuge.se (Peter Stuge) Date: Fri, 30 Apr 2010 09:52:45 +0200 Subject: disable comitting of files In-Reply-To: References: Message-ID: <20100430075245.5698.qmail@stuge.se> Andreas.Eversberg wrote: > i like to change some tracked files without committing them. when i > do "git commit -a", every change is comitted. > > sometimes i like to play with layer1 code or even change Makefile.inc, > but i don't want to reset my changes before committing. > > any idea how to create a list of omitted files? Two ways: "git commit -a" = "git add ." + "git commit" You can use git add directly, to control exactly what is included in the index (tracked) and later committed. Then you run only git commit to create the commit. As an alternative or perhaps complement, if making temporary changes for testing in the middle of something else, check out git stash. It pushes all uncommitted changes onto a temporary patch stash, and they can be recalled easily later. //Peter