From holger at freyther.de Fri Apr 3 17:37:42 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 3 Apr 2015 19:37:42 +0200 Subject: [PATCH] Fix lintian-reported errors In-Reply-To: <20150325234423.GO540@xiaoyu.lan> References: <1427303161-6552-1-git-send-email-max.suraev@fairwaves.co> <20150325234423.GO540@xiaoyu.lan> Message-ID: <20150403173742.GL1127@xiaoyu.lan> On Thu, Mar 26, 2015 at 12:44:23AM +0100, Holger Hans Peter Freyther wrote: > On Wed, Mar 25, 2015 at 06:06:01PM +0100, Max wrote: max, could you please provide an updated/separated patch to at least improve the parts that are obviously correct and needed? From holger at freyther.de Sun Apr 5 12:42:00 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 5 Apr 2015 14:42:00 +0200 Subject: [PATCH] Add A5/3-4 cipher support In-Reply-To: <5512EC29.3010900@fairwaves.co> References: <1427300431-20371-1-git-send-email-max.suraev@fairwaves.co> <5512EC29.3010900@fairwaves.co> Message-ID: <20150405124200.GA13606@xiaoyu.lan> On Wed, Mar 25, 2015 at 06:11:05PM +0100, ? wrote: Dear Max, > Previous patch http://patchwork.ozlabs.org/patch/360531/ bitrot - ported to latest > master and hope to get some feedback. a5/a5_test.c: In function ?test_a53?: a5/a5_test.c:60:2: warning: implicit declaration of function ?_a5_3? [-Wimplicit-function-declaration] _a5_3(key, count, dlout, NULL, false); ^ a5/a5_test.c: In function ?test_a54?: a5/a5_test.c:72:2: warning: implicit declaration of function ?_a5_4? [-Wimplicit-function-declaration] _a5_4(key, count, dlout, NULL, false); in case the above come from your patch, please fix these warnings. From max.suraev at fairwaves.co Mon Apr 6 14:17:49 2015 From: max.suraev at fairwaves.co (Max) Date: Mon, 6 Apr 2015 16:17:49 +0200 Subject: [PATCH] fix compiler warnings for a5 tests Message-ID: <1428329869-21475-1-git-send-email-max.suraev@fairwaves.co> Signed-off-by: Max --- tests/a5/a5_test.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tests/a5/a5_test.c b/tests/a5/a5_test.c index 0dbc6fb..6d7cc3c 100644 --- a/tests/a5/a5_test.c +++ b/tests/a5/a5_test.c @@ -8,6 +8,10 @@ #include #include +// make compiler happy +void _a5_3(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul, bool fn_correct); +void _a5_4(const uint8_t *key, uint32_t fn, ubit_t *dl, ubit_t *ul, bool fn_correct); + static const uint8_t key[] = { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef }; static const uint32_t fn = 123456; static const uint8_t dl[] = { -- 2.1.0 From Max.Suraev at fairwaves.co Wed Apr 8 11:46:11 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Wed, 08 Apr 2015 13:46:11 +0200 Subject: [PATCH] Add A5/3-4 cipher support In-Reply-To: <20150405124200.GA13606@xiaoyu.lan> References: <1427300431-20371-1-git-send-email-max.suraev@fairwaves.co> <5512EC29.3010900@fairwaves.co> <20150405124200.GA13606@xiaoyu.lan> Message-ID: <55251503.2020108@fairwaves.co> Here it is: http://patchwork.ozlabs.org/patch/458387/ 05.04.2015 14:42, Holger Hans Peter Freyther ?????: > On Wed, Mar 25, 2015 at 06:11:05PM +0100, ? wrote: > > Dear Max, > >> Previous patch http://patchwork.ozlabs.org/patch/360531/ bitrot - ported to latest >> master and hope to get some feedback. > > a5/a5_test.c: In function ?test_a53?: > a5/a5_test.c:60:2: warning: implicit declaration of function ?_a5_3? [-Wimplicit-function-declaration] > _a5_3(key, count, dlout, NULL, false); > ^ > a5/a5_test.c: In function ?test_a54?: > a5/a5_test.c:72:2: warning: implicit declaration of function ?_a5_4? [-Wimplicit-function-declaration] > _a5_4(key, count, dlout, NULL, false); > > > in case the above come from your patch, please fix these warnings. > -- best regards, Max, http://fairwaves.co From Max.Suraev at fairwaves.co Wed Apr 8 11:52:22 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Wed, 08 Apr 2015 13:52:22 +0200 Subject: [PATCH] Fix lintian-reported errors In-Reply-To: <20150403173742.GL1127@xiaoyu.lan> References: <1427303161-6552-1-git-send-email-max.suraev@fairwaves.co> <20150325234423.GO540@xiaoyu.lan> <20150403173742.GL1127@xiaoyu.lan> Message-ID: <55251676.4070401@fairwaves.co> 03.04.2015 19:37, Holger Hans Peter Freyther ?????: > On Thu, Mar 26, 2015 at 12:44:23AM +0100, Holger Hans Peter Freyther wrote: >> On Wed, Mar 25, 2015 at 06:06:01PM +0100, Max wrote: > > max, could you please provide an updated/separated patch to > at least improve the parts that are obviously correct and > needed? > Sure that's on my TODO alongside with writing better descriptions based on wiki pages. Can't give any ETA though so if anyone is willing to step in - go ahead. -- best regards, Max, http://fairwaves.co From craig_comstock at yahoo.com Thu Apr 16 11:51:06 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 16 Apr 2015 11:51:06 +0000 (UTC) Subject: nuttx-bb? Message-ID: <947230410.4267258.1429185067070.JavaMail.yahoo@mail.yahoo.com> Hi all, Was starting to work on making a usable phone again and wondered about the status of nuttx-bb git on osmocom.org versus nuttx source. It seems nuttx source is more up-to-date and has configs for my device: compal_e86/c139. Wondering if there is something in nuttx-bb that is unique that I should pay attention to? Should nuttx-bb be rebased from nuttx upstream? I was able to cobble together a nuttx.bin but on loading it always stops at 88% with the chainloader. The nuttx.bin is 148K which would seem plenty of room since the C139 has 4000K flash (32MBit) (am I doing that calculation correctly)? I had to fiddle with the MEMORY section of the ld.script in order to make space for nuttx, I'm not too familiar with this sort of thing so may have done something wrong... /* E86 stacked flash 32mbit flash, 4mbit sram, DBB internal 256kb SRAM */ ??? /* 0x800000-0x87ffff */ /* bump up because we have 32mbit instead of 16mbit */ ??? /* compal-loaded binary: our text, initialized data */ ??? LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000 ??? TRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00040000 ??? /* compal-loaded binary: our unitialized data, stacks, heap */ ??? IRAM (rw) : ORIGIN = 0x00860000, LENGTH = 0x00020000 Originally TRAM was 20000 long and gave me an error on building. Not sure if I can fiddle with these values or not. Thanks,Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: diff2 Type: application/octet-stream Size: 4233 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmocon.log Type: text/x-log Size: 3339 bytes Desc: not available URL: From craig_comstock at yahoo.com Fri Apr 17 00:51:41 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 17 Apr 2015 00:51:41 +0000 (UTC) Subject: nuttx-bb? References: <947230410.4267258.1429185067070.JavaMail.yahoo@mail.yahoo.com> Message-ID: Craig Comstock yahoo.com> writes: > > > Hi all, > > Was starting to work on making a usable phone again and wondered about the status of nuttx-bb git on osmocom.org versus nuttx source. It seems nuttx source is more up-to-date and has configs for my device: compal_e86/c139. Wondering if there is something in nuttx-bb that is unique that I should pay attention to? Should nuttx-bb be rebased from nuttx upstream? > > I was able to cobble together a nuttx.bin but on loading it always stops at 88% with the chainloader. The nuttx.bin is 148K which would seem plenty of room since the C139 has 4000K flash (32MBit) (am I doing that calculation correctly)? > > I had to fiddle with the MEMORY section of the ld.script in order to make space for nuttx, I'm not too familiar with this sort of thing so may have done something wrong... > > /* E86 stacked flash 32mbit flash, 4mbit sram, DBB internal 256kb SRAM */??? /* 0x800000-0x87ffff */ /* bump up because we have 32mbit instead of 16mbit */??? /* compal-loaded binary: our text, initialized data */??? LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000??? TRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00040000??? /* compal-loaded binary: our unitialized data, stacks, heap */??? IRAM (rw) : ORIGIN = 0x00860000, LENGTH = 0x00020000 > > > Originally TRAM was 20000 long and gave me an error on building. Not sure if I can fiddle with these values or not. > > > Thanks, > Craig > > > > Attachment (diff2): application/octet-stream, 4233 bytes > Attachment (osmocon.log): text/x-log, 3339 bytes I did some debugging on osmocon and it seems it is getting stuck on the serial read not returning anything, maybe blocking forever waiting for data coming back. I wasn't sure how the chainloader program was loaded... there seemed to be 30-40 bytes of code in an array maybe? Maybe the chainloader is being corrupted? Other chainloaded programs such as rssi work just fine so maybe my nuttx.bin is causing a problem somehow. Thanks, Craig From craig_comstock at yahoo.com Fri Apr 17 04:50:04 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 17 Apr 2015 04:50:04 +0000 (UTC) Subject: nuttx-bb? References: <947230410.4267258.1429185067070.JavaMail.yahoo@mail.yahoo.com> Message-ID: Craig Comstock yahoo.com> writes: > > Craig Comstock yahoo.com> writes: > > > > > > > Hi all, > > > > Was starting to work on making a usable phone again and wondered about the > status of nuttx-bb git on osmocom.org versus nuttx source. It seems nuttx > source is more up-to-date and has configs for my device: compal_e86/c139. > Wondering if there is something in nuttx-bb that is unique that I should pay > attention to? Should nuttx-bb be rebased from nuttx upstream? > > > > I was able to cobble together a nuttx.bin but on loading it always stops > at 88% with the chainloader. The nuttx.bin is 148K which would seem plenty > of room since the C139 has 4000K flash (32MBit) (am I doing that calculation > correctly)? > > > > I had to fiddle with the MEMORY section of the ld.script in order to make > space for nuttx, I'm not too familiar with this sort of thing so may have > done something wrong... > > > > /* E86 stacked flash 32mbit flash, 4mbit sram, DBB internal 256kb SRAM > */??? /* 0x800000-0x87ffff */ /* bump up because we have 32mbit instead of > 16mbit */??? /* compal-loaded binary: our text, initialized data */??? LRAM > (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000??? TRAM (rw) : ORIGIN = > 0x00820000, LENGTH = 0x00040000??? /* compal-loaded binary: our unitialized > data, stacks, heap */??? IRAM (rw) : ORIGIN = 0x00860000, LENGTH = 0x00020000 > > > > > > Originally TRAM was 20000 long and gave me an error on building. Not sure > if I can fiddle with these values or not. > > > > > > Thanks, > > Craig > > > > > > > > Attachment (diff2): application/octet-stream, 4233 bytes > > Attachment (osmocon.log): text/x-log, 3339 bytes > > I did some debugging on osmocon and it seems it is getting stuck on the > serial read not returning anything, maybe blocking forever waiting for data > coming back. I wasn't sure how the chainloader program was loaded... there > seemed to be 30-40 bytes of code in an array maybe? Maybe the chainloader is > being corrupted? Other chainloaded programs such as rssi work just fine so > maybe my nuttx.bin is causing a problem somehow. > > Thanks, > Craig > > I tried chopping the binary down to 130 chunks of 1014 bytes, i.e. 128kb bytes, and that loads fine. So maybe this TI Calypso romloader can only load 128kb? The osmocom c140 page mentions 256kb of internal SRAM. Can anyone give me some clues here? I suppose the c139 might have a different Calypso chip with only 128kb internal sram? Does this have something to do with the extra control register ffff:fb10 it has a note that mentions access ending at some point... 0 = Accessing nCS3 with programmed wait-state. 1 = When accessing nCS3 the number of wait is set to 127, but access is ended when nready_mem goes low. If nready_mem stays at ?1? after 127 wait states an abort is generated. I read a bunch of old messages on this list about nuttx b/w Greg and Harald and learned a lot. Sounds like running NuttX from flash and then loading GSM-specific "apps" into SRAM is sort of the best idea? If anyone else is working on nuttx-bb or maybe porting mobile onto the phone it would be great to collaborate. From domi at tomcsanyi.net Thu Apr 23 16:01:15 2015 From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi=2C?= Domonkos) Date: Thu, 23 Apr 2015 18:01:15 +0200 (CEST) Subject: [PATCH] SAP client - revisited Message-ID: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> Hi everyone, I'm following up on this conversation: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/1796 It seems like there was no movement in this topic in the last couple of years, so I decided to go ahead and integrate Nico's SAP client into the current master branch and created a patch from it. I tested it (with Kevin's softSIM and a pcsc reader), it worked for me, however it is currently quite ugly: it kind of hand crafts the msgb structure (in l1ctl.c, patch line 121), sorry for that, but I kept getting extra bytes stuffed into the msg that was passed to the sap_interface so I decided to manually go around the problem. I'm of course open to any suggestions to get it cleaner, and then if you think and decide so it could be merged into the master (as far as I see. One thing however that I think is strange, and worth mentioning: I'm not sure why Nico decided to implement the switch between phone and SAP-client inside of l1ctl.c, for me it would feel better to do it in sim.c (since sim.c deals with SIM activities, l1ctl should deal only with L1 stuff...also the current SAP client calls back to sim.c, but receives data from l1ctl - little bit confusing), but I left it as is because of not knowing exactly the thoughts behind it. Regards, Domi -------------- next part -------------- A non-text attachment was scrubbed... Name: sap.patch Type: text/x-patch Size: 23863 bytes Desc: not available URL: From osmocom at ngolde.de Fri Apr 24 14:41:53 2015 From: osmocom at ngolde.de (Nico Golde) Date: Fri, 24 Apr 2015 16:41:53 +0200 Subject: [PATCH] SAP client - revisited In-Reply-To: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> References: <1015750550.17043.1429804875628.JavaMail.zimbra@tomcsanyi.net> Message-ID: <20150424144153.GB9119@ngolde.de> Hi, * Tomcs?nyi, Domonkos [2015-04-23 18:12]: [...] > It seems like there was no movement in this topic in the last couple of years, so I decided to go ahead and integrate Nico's SAP client into the current master branch and created a patch from it. Cool, great work! > One thing however that I think is strange, and worth mentioning: I'm not > sure why Nico decided to implement the switch between phone and SAP-client > inside of l1ctl.c, for me it would feel better to do it in sim.c (since > sim.c deals with SIM activities, l1ctl should deal only with L1 stuff...also > the current SAP client calls back to sim.c, but receives data from l1ctl - > little bit confusing), but I left it as is because of not knowing exactly > the thoughts behind it. I don't remember details to be honest as this is too long ago, but I think there was no real design decision behind this other than that the code that is sending traffic to the SIM was already in l1ctl and I just added the switch... Cheers, Nico -- Nico Golde - XMPP: nion at jabber.ccc.de - GPG: 0xA0A0AAAA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: