simtrace

simtrace@lists.osmocom.org

350 discussions

Save the Date: OsmoCon 2018 on October 18-19, 2018
by Harald Welte 11 Apr '18

11 Apr '18

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Compiling and running simtrace firmware with a recent toolchain
by Denis 'GNUtoo' Carikli 09 Mar '18

09 Mar '18

Hi, The simtrace firmware is in the OpenPCD git repository at: > git://git.osmocom.org/openpcd.git I used the last revision at the time of writing: > dc2983d firmware: Makefiles: enable changing toolchain With a fairly recent gcc version: > $ arm-none-eabi-gcc --version > arm-none-eabi-gcc (Arch Repository) 7.3.0 > Copyright (C) 2017 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. Compiling the firmware the usual way works, with many warnings: > $ make BOARD=SIMTRACE DEBUG=1 TARGET=main_simtrace \ > CROSS_COMPILE=arm-none-eabi- [...] Installing that firmware went fine: > $ sudo dfu-util -d 16c0:0762 -a0 -D ./main_simtrace.bin -R > dfu-util 0.9 > > Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. > Copyright 2010-2016 Tormod Volden and Stefan Schmidt > This program is Free Software and has ABSOLUTELY NO WARRANTY > Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ > > dfu-util: Invalid DFU suffix signature > dfu-util: A valid DFU suffix will be required in a future dfu-util > release!!! Opening DFU capable USB device... > ID 16c0:0762 > Run-time device DFU version 0100 > Claiming USB DFU Interface... > Setting Alternate Setting #0 ... > Determining device status: state = dfuIDLE, status = 0 > dfuIDLE, continuing > DFU mode device DFU version 0100 > Device returned transfer size 256 > Copying data from PC to DFU device > Download [=========================] 100% 23084 bytes > Download done. > state(7) = dfuMANIFEST, status(0) = No error condition is present > state(2) = dfuIDLE, status(0) = No error condition is present > Done! > dfu-util: can't detach > Resetting USB to switch back to runtime mode Unfortunately with the new compiler the device gets re-enumerated continuously: > usb 4-1: new full-speed USB device number 3 using uhci_hcd > usb 4-1: new full-speed USB device number 4 using uhci_hcd > usb 4-1: new full-speed USB device number 5 using uhci_hcd [...] Here's what I have on the serial port: > [000000] > [000001] (C) 2006-2011 by Harald Welte <hwelte(a)hmw-consulting.de> > This software is FREE SOFTWARE licensed under GNU GPL > [000002] Version 0.5.30-dc29 compiled 20180309-165435 by gnutoo@second-laptop > > [000003] > DEBUG Interface: > 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 > 9) Reset > [000004] RSTC_SR=0x00010000 > [000005] LARGE req_ctx[00] initialized at 002055AC, Data: 00200A68 => 00200E28 > [000006] LARGE req_ctx[01] initialized at 002055C0, Data: 00200E28 => 002011E8 > [000007] LARGE req_ctx[02] initialized at 002055D4, Data: 002011E8 => 002015A8 > [000008] LARGE req_ctx[03] initialized at 002055E8, Data: 002015A8 => 00201968 > [000009] LARGE req_ctx[04] initialized at 002055FC, Data: 00201968 => 00201D28 > [00000A] LARGE req_ctx[05] initialized at 00205610, Data: 00201D28 => 002020E8 > [00000B] LARGE req_ctx[06] initialized at 00205624, Data: 002020E8 => 002024A8 > [00000C] LARGE req_ctx[07] initialized at 00205638, Data: 002024A8 => 00202868 > [00000D] LARGE req_ctx[08] initialized at 0020564C, Data: 00202868 => 00202C28 > [00000E] LARGE req_ctx[09] initialized at 00205660, Data: 00202C28 => 00202FE8 > [00000F] LARGE req_ctx[10] initialized at 00205674, Data: 00202FE8 => 002033A8 > [000010] LARGE req_ctx[11] initialized at 00205688, Data: 002033A8 => 00203768 > [000011] LARGE req_ctx[12] initialized at 0020569C, Data: 00203768 => 00203B28 > [000012] LARGE req_ctx[13] initialized at 002056B0, Data: 00203B28 => 00203EE8 > [000013] LARGE req_ctx[14] initialized at 002056C4, Data: 00203EE8 => 002042A8 > [000014] LARGE req_ctx[15] initialized at 002056D8, Data: 002042A8 => 00204668 > [000015] LARGE req_ctx[16] initialized at 002056EC, Data: 00204668 => 00204A28 > [000016] LARGE req_ctx[17] initialized at 00205700, Data: 00204A28 => 00204DE8 > [000017] LARGE req_ctx[18] initialized at 00205714, Data: 00204DE8 => 002051A8 > [000018] LARGE req_ctx[19] initialized at 00205728, Data: 002051A8 => 00205568 > [000019] Inititalizing usbcmd_gen_init > [00001A] udp_open(440): entering > [00001B] USART Initializing > [00001C] pio_irq_register(109): registering handler 001079bc for PIOA 7 > [00001D] RST > [00001E] computed Fi(1) Di(1) ratio: 372 > [000000] > [000001] (C) 2006-2011 by Harald Welte <hwelte(a)hmw-consulting.de> > This software is FREE SOFTWARE licensed under GNU GPL > [000002] Version 0.5.30-dc29 compiled 20180309-165435 by gnutoo@second-laptop > > [000003] > DEBUG Interface: > 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 > 9) Reset > [000004] RSTC_SR=0x00010200 > [000005] LARGE req_ctx[00] initialized at 002055AC, Data: 00200A68 => 00200E28 > [000006] LARGE req_ctx[01] initialized at 002055C0, Data: 00200E28 => 002011E8 > [000007] LARGE req_ctx[02] initialized at 002055D4, Data: 002011E8 => 002015A8 > [000008] LARGE req_ctx[03] initialized at 002055E8, Data: 002015A8 => 00201968 > [000009] LARGE req_ctx[04] initialized at 002055FC, Data: 00201968 => 00201D28 > [00000A] LARGE req_ctx[05] initialized at 00205610, Data: 00201D28 => 002020E8 > [00000B] LARGE req_ctx[06] initialized at 00205624, Data: 002020E8 => 002024A8 > [00000C] LARGE req_ctx[07] initialized at 00205638, Data: 002024A8 => 00202868 > [00000D] LARGE req_ctx[08] initialized at 0020564C, Data: 00202868 => 00202C28 > [00000E] LARGE req_ctx[09] initialized at 00205660, Data: 00202C28 => 00202FE8 > [00000F] LARGE req_ctx[10] initialized at 00205674, Data: 00202FE8 => 002033A8 > [000010] LARGE req_ctx[11] initialized at 00205688, Data: 002033A8 => 00203768 > [000011] LARGE req_ctx[12] initialized at 0020569C, Data: 00203768 => 00203B28 > [000012] LARGE req_ctx[13] initialized at 002056B0, Data: 00203B28 => 00203EE8 > [000013] LARGE req_ctx[14] initialized at 002056C4, Data: 00203EE8 => 002042A8 > [000014] LARGE req_ctx[15] initialized at 002056D8, Data: 002042A8 => 00204668 > [000015] LARGE req_ctx[16] initialized at 002056EC, Data: 00204668 => 00204A28 > [000016] LARGE req_ctx[17] initialized at 00205700, Data: 00204A28 => 00204DE8 > [000017] LARGE req_ctx[18] initialized at 00205714, Data: 00204DE8 => 002051A8 > [000018] LARGE req_ctx[19] initialized at 00205728, Data: 002051A8 => 00205568 > [000019] Inititalizing usbcmd_gen_init > [00001A] udp_open(440): entering > [00001B] USART Initializing > [00001C] pio_irq_register(109): registering handler 001079bc for PIOA 7 > [00001D] RST > [00001E] computed Fi(1) Di(1) ratio: 372 > [000000] So it gets reset in a loop. I can get it to work with the following diff: --- a/firmware/src/simtrace/tc_etu.c +++ b/firmware/src/simtrace/tc_etu.c @@ -96,8 +96,8 @@ void tc_etu_init(void) ((unsigned int) 1 << AT91C_ID_TC0)); /* Connect TCLK0 to XC0 */ - tcb->TCB_BMR &= ~(AT91C_TCB_TC0XC0S); - tcb->TCB_BMR |= AT91C_TCB_TC0XC0S_TCLK0; +// tcb->TCB_BMR &= ~(AT91C_TCB_TC0XC0S); +// tcb->TCB_BMR |= AT91C_TCB_TC0XC0S_TCLK0; /* Register Interrupt handler */ AT91F_AIC_ConfigureIt(AT91C_BASE_AIC, AT91C_ID_TC0, @@ -124,5 +124,5 @@ void tc_etu_init(void) tcetu->TC_CCR = AT91C_TC_CLKEN; /* Reset to start timers */ - tcb->TCB_BCR = 1; +// tcb->TCB_BCR = 1; } With the diff I have the following on serial: > [000000] > [000001] (C) 2006-2011 by Harald Welte <hwelte(a)hmw-consulting.de> > This software is FREE SOFTWARE licensed under GNU GPL > [000002] Version 0.5.30-dc29-dirty compiled 20180309-165717 by gnutoo@second-laptop > > [000003] > DEBUG Interface: > 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 > 9) Reset > [000004] RSTC_SR=0x00010000 > [000005] LARGE req_ctx[00] initialized at 00205630, Data: 00200AEC => 00200EAC > [000006] LARGE req_ctx[01] initialized at 00205644, Data: 00200EAC => 0020126C > [000007] LARGE req_ctx[02] initialized at 00205658, Data: 0020126C => 0020162C > [000008] LARGE req_ctx[03] initialized at 0020566C, Data: 0020162C => 002019EC > [000009] LARGE req_ctx[04] initialized at 00205680, Data: 002019EC => 00201DAC > [00000A] LARGE req_ctx[05] initialized at 00205694, Data: 00201DAC => 0020216C > [00000B] LARGE req_ctx[06] initialized at 002056A8, Data: 0020216C => 0020252C > [00000C] LARGE req_ctx[07] initialized at 002056BC, Data: 0020252C => 002028EC > [00000D] LARGE req_ctx[08] initialized at 002056D0, Data: 002028EC => 00202CAC > [00000E] LARGE req_ctx[09] initialized at 002056E4, Data: 00202CAC => 0020306C > [00000F] LARGE req_ctx[10] initialized at 002056F8, Data: 0020306C => 0020342C > [000010] LARGE req_ctx[11] initialized at 0020570C, Data: 0020342C => 002037EC > [000011] LARGE req_ctx[12] initialized at 00205720, Data: 002037EC => 00203BAC > [000012] LARGE req_ctx[13] initialized at 00205734, Data: 00203BAC => 00203F6C > [000013] LARGE req_ctx[14] initialized at 00205748, Data: 00203F6C => 0020432C > [000014] LARGE req_ctx[15] initialized at 0020575C, Data: 0020432C => 002046EC > [000015] LARGE req_ctx[16] initialized at 00205770, Data: 002046EC => 00204AAC > [000016] LARGE req_ctx[17] initialized at 00205784, Data: 00204AAC => 00204E6C > [000017] LARGE req_ctx[18] initialized at 00205798, Data: 00204E6C => 0020522C > [000018] LARGE req_ctx[19] initialized at 002057AC, Data: 0020522C => 002055EC > [000019] Inititalizing usbcmd_gen_init > [00001A] udp_open(440): entering > [00001B] USART Initializing > [00001C] pio_irq_register(109): registering handler 001079bc for PIOA 7 > [00001D] RST > [00001E] computed Fi(1) Di(1) ratio: 372 > [00001F] ISO_SW Initializing > [000020] pio_irq_register(109): registering handler 00107fb0 for PIOA 8 > [000021] pio_irq_register(109): registering handler 00107fdc for PIOA 25 > [000022] VCC_PHONE off > [000023] USART Entering Rx Mode > [000024] RST > [000025] computed Fi(1) Di(1) ratio: 372 > [000026] MODE: SNIFFER > > [000027] RST > [000028] computed Fi(1) Di(1) ratio: 372 > [000029] main(76): entering main (idle) loop > [00002A] Heart beat 00000000 > [00002B] Heart beat 00000001 > [00002C] Heart beat 00000002 > [00002D] Heart beat 00000003 > [00002E] Heart beat 00000004 > [00002F] Heart beat 00000005 And I could even get some packet trace from my Galaxy SIII (i9300): > GSM SIM 80 3 9f : 00d2 > GSM SIM 67 ISO/IEC 7816-4 SELECT File MF > GSM SIM 67 ISO/IEC 7816-4 SELECT /EF.ELP > GSM SIM 90 ISO/IEC 7816-4 GET RESPONSE > GSM SIM 75 ISO/IEC 7816-4 READ BINARY Offset=0 > GSM SIM 67 ISO/IEC 7816-4 SELECT File EF.ICCID > GSM SIM 90 ISO/IEC 7816-4 GET RESPONSE > GSM SIM 75 ISO/IEC 7816-4 READ BINARY Offset=0 > GSM SIM 85 ETSI TS 102.221 TERMINAL PROFILE > GSM SIM 67 ISO/IEC 7816-4 SELECT File EF.DIR > GSM SIM 93 ISO/IEC 7816-4 GET RESPONSE > GSM SIM 103 ISO/IEC 7816-4 READ RECORD RecordNr=1 > GSM SIM 81 ISO/IEC 7816-4 SELECT Application a0000000871002ff33ff018900000100 > GSM SIM 108 ISO/IEC 7816-4 GET RESPONSE > GSM SIM 67 ISO/IEC 7816-4 SELECT File MF Denis.

1 0

SIM select file (A4) command
by Thomas Chen 21 Feb '18

21 Feb '18

i noticed the GSM modem issued a couple SELECT (a4) commands that i cannot find the documentation for would any one be able to help identify these ??? thanks 00 a4 00 04 02 7f ff 00 a4 00 04 02 7f 66 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 3

OsmoDevCon 2018 schedule planning
by Harald Welte 06 Dec '17

06 Dec '17

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] Like every year in early December, it is time to discuss as schedule for OsmoDevCon in the upcoming year. Note: Ths is about OsmoDevCon, the more private meeting of developers, *NOT* about OsmoCon, the public conference. == When, Who, Where == I propose the following date for OsmoDevCon 2018: April 20 - April 23rd, 2018 * Who: Active developers/contributors of Osmocom projects (as usual) * Where: IN-Berlin, Berlin (as usual) Please let me know ASAP if that proposed date works for everyone who'd want to attend. We can still change it now, but I would want to nail down the date pretty soon. == Format == After the experiment of reducing from 4 to 3 days last year (due to OsmoCon), we will again go for *four days* in 2018. However, we should clearly divide the days in a way that e.g. "GSM/3G" topics are on two days, while SDR+Other topics are on the other days, so people not interested in some topics can skip one or two days, as needed. We could even divide it further like: * 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...) * 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.) * 2 days misc Regards, and looking forward to meeting you [again] in 2018, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1

SAM3 DFU
by Thomas Chen 30 Nov '17

30 Nov '17

question about DFU... working with AT91SAM3 board, i tried, 1. use sam-ba to flash the DFU image (works fine) 2. try to use dfu-util to flash the APP, but it does not seem to write into flash (after reboot we still have the initial DFU image ??) (i am using the same argument as SAM7 -a0 -D filename -R is there any tips you can provide before i start digging ?

3 2

remote sim network delay
by Thomas Chen 27 Nov '17

27 Nov '17

i am not clear about how simtrace2, specifically libcommon/source/card_emu.c seems to handle the network delay for remote sim response however, i dont understand how that would help ??? my understand of the protocol is that ME => SIM (first 5 bytes of APDU) SIM <=== PROCEDURE (either INS as ack, or 0x60 to hold up the protocol) but that does not help remote sim, as remote SIM would need the susequent bytes which will not come until we send back INS, so just holding off ME with 0x60 does not alleviate the problem of network delay

4 6

Min Xu patches testing (Lukas Kuzmiak)
by Min Xu 03 Nov '17

03 Nov '17

Hi Lukas I saw your email to my @sanjole.com address but since this address is on the mailing list I'll just reply here so everyone can see. --- your email below --- Hi Min Xu, first of all thanks for all the work you put into simtrace. I’ve been testing your patches last couple days, they have not yet been in any release which I think is a shame, so I’d like to push the community to fix that so it can be even further tested (by testing, reporting back, fixing building the firmware with latest arm-none-eabi, etc.) I have found one bug for which I fail to identify the source .. The whole trace is fine except sometimes there are 4 bytes inside the data which seems to be the simtrace_hdr (first line is my debug): USB MSG: sh->cmd: 1, sh->flags: 0, sh->res[9, 5], payload: 00 a4 00 04 02 a4 6f 07 61 2a 00 c0 00 00 2a c0 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 01 00 09 05 00 b0 00 00 09 b0 08 29 03 30 10 66 03 91 12 90 00 APDU: 00 a4 00 04 02 6f 07 61 2a APDU: 00 c0 00 00 2a 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 APDU: 01 00 09 05 00 b0 00 APDU: 00 09 b0 08 29 03 30 APDU: 10 66 03 91 12 90 00 The 01 00 09 05 (which seems to be sh->cmd, sh->flags and Fi/Di (9/5) just randomly appear in APDU data every now and then. If those 4 bytes were not there apdu_split would split it fine .. like this it breaks this into nonsense pieces and breaks the trace. I’ve gone through your patches in the firmware, fiddled around with some of them but didn’t manage to find the root cause yet - seems like the simtrace_hdr is inserted in the middle (but that does not seem possible), so perhaps 2 USB messages somehow get merged into one? So I figured I’ll try to write you, maybe it will ring a bell - I have not fully verified the merge of your patches went correctly but from a fast compare it seems like it. If you’ll find a minute to give me a few tips I’ll appreciate that, in the meantime I’ll keep digging. PS: the version of FW I’m using is latest master in the git (https://git.osmocom.org/openpcd). Thanks! Lukas --- END --- I believe the reason for this is actually in an email I sent to the list on Sep 10, 2013. Basically, the ATMEL chip can break up the req_ctx ( the usb response ) and combine as it see fit (if there's a large burst etc). So you cannot rely on the "natural break" between the calls to transmit. Therefore, since it's a stream you'll get on receiving side, then a natural packet header that accounts of subsequent bytes must be added. So I added extra bytes into the simtrace_hdr header so that the actual data payload can be correctly accounted for. The changes are: struct simtrace_hdr { u_int8_t cmd; u_int8_t flags; u_int8_t res[2]; + u_int16_t seq_num; + u_int16_t offset; + u_int16_t tot_len; u_int8_t data[0]; } __attribute__ ((packed)); So the desktop client will have to have equivalent changes to account for these extra fields. Let me know if this answers your question. If not I can try send you the full code I have for the firmware and a sample of the desktop receiving / parsing code so you'll have a baseline.

2 2

Min Xu patches testing
by Lukas Kuzmiak 03 Nov '17

03 Nov '17

Hi again guys, I've been testing the latest firmware (git master) to see how patches from Min Xu made it better and tracing of fast sims (lost bytes, broken tracing, etc.) seems to be a lot improved. I have found one bug - somehow simtrace_hdr makes it into the APDU payloads, I've been trying to find the root cause of this but have not managed yet - seems like the FW sends 2 messages but they arrive as a single message into the host software thus the header is considered APDU payload. I've reported the issue here: https://osmocom.org/issues/2614 along with all the tracing/investigation I've performed so far - anybody got further ideas how this might happen? Other than this and the painful building of the firmware in today's world it seems tracing modern phones is not such a pain as it used to be, yay! Lukas

1 0

building simtrace FW nowdays
by Lukas Kuzmiak 03 Nov '17

03 Nov '17

Hi guys, after a long time I blew the dust off of mine SIMtrace 1.0p, went through the history of the mailing list archives and saw there were some nice fixes for fast sims but there is no released firmware that includes them (v0.5 is latest dated in 2012 - I still have some sync issues/lost bytes with v0.5 like i used to years ago). So I got to building and oh boy :-) Back in the day arm-elf was not obsolete and all went fine, today with arm-none-eabi however, not so much. After couple days of fiddling around with building custom toolchains, trying the ones from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads <https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads> and other goodies I realized I keep running into the same issue over and over again. Some kind of a weird boot loop - see UART log attached. Weirdly enough the DFU compiles fine with the gcc-arm-none-eabi-6-2017-q2-update toolchain and works just fine, it seem main_simtrace also compiles, links and even starts initializing but then dies somewhere in the middle. I never got pass this "[00001E] computed Fi(1) Di(1) ratio: 372” to “ISO_SW Initializing” .. Have not managed to figure out why - any help appreciated on this. In the end I went all the way back to gcc-4.6.4, had to apply some patches do it’d compile on a recent Debian (9.2) .. and using arm-elf toolchain produces a working firmware (after reverting commit 373c172ab858102e1818c8476ab1a2b290685cda "convert from u_int*_t to uint*_t”). For anybody in this situation see the procedure below (for reference). Hopefully the issue can be collaboratively fixed - I’m happy to test around on 1.0p and 1.4p boards, different toolchains etc. but I don’t really know how to debug the bootloop - even a nudge in that is appreciated. Btw - is it possible to get write access to SIMtrace wiki? There’s a bunch of stuff that could be fixed :) eg. i had to dig sam7utils from archive.org <http://archive.org/> (openpcd.org <http://openpcd.org/> no longer has it) and some other misc stuff. IMHO if this can be fixed a v0.6 release could be made after (or even before) to bring those fast sim features to people in a simpler fashion? I have yet to test that functionality on my end - I can report back on how it seems to perform (not sure how widely tested it has been). Lukas GCC-4.6.4 (arm-elf) on Debian 9.2: - use the gnu-arm-build.3.sh script from https://osmocom.org/projects/baseband/wiki/GnuArmToolchain <https://osmocom.org/projects/baseband/wiki/GnuArmToolchain> - apply a patch below to the script, gcc.patch is https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00375.html <https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00375.html>, gcc.texi.patch is https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html <https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html> - voila, compile simtrace firmware (git revert —no-commit 373c172ab858102e1818c8476ab1a2b290685cda - if you’re using master). 8,9c8,9 < GCC_SRC=gcc-4.8.2.tar.bz2 < GCC_VERSION=4.8.2 --- > GCC_SRC=gcc-4.6.4.tar.bz2 > GCC_VERSION=4.6.4 20c20 < TARGET_TRIPLET=arm-none-eabi --- > TARGET_TRIPLET=arm-elf 69a70,78 > > # > # Stage 0: Patch the old gcc so it compiles on modern systems > # > ( > cd $SRCDIR/$GCC_DIR > patch -p1 < ../../gcc.patch > patch -p1 < ../../gcc.texi.patch > ) || exit 1

1 0

Want to do paid work on Osmocom? sysmocom is hiring
by Harald Welte 31 Oct '17

31 Oct '17

Dear Osmocom community, I would like to point out that at sysmocom, we're currently (again) hiring [1]. If you happen to have an interest in open source cellular communications and are fluent in C language development, we would love to hear from you. sysmocom probably doesn't need any introduction here, but just in case: The company was founded by Holger Freyther and Harald Welte, two of the leading OpenBSC and Osmocom developers from the very early days of the project. Today we are responsible for by far the largest number of commits to the Osmocom GSM/3G infrastructure related git repositories. Among our current priorities are automatic testing for the GPRS PCU, generalization of the OsmoMGW media gateway, support for load-based hand-over, inter-BSC hand-over as well as various improvements on the lower layers of the GPRS protocol stack. We're very dedicated to the cause in furthering the capabilities of open source cellular infrastructure from 2G to 4G. We believe in working upstream, no open core or dual licensing. If you have an interest working with an enthusiastic, strong technical and dedicated team of Osmocom hackers, please don't hesitate to let me know, best by e-mail to jobs(a)sysmocom.de Thanks, Harald p.s.: I hope this kind of message is not disturbing to anyone. I think it is important to the Osmocom project to have more paid people working on the stack, so it is justified. The positions we are seeking to fill will work [almost exclusively] on Osmocom, so it's not a random job ad but in the very interest of Osmocom, and hence on-topic for this list. [1] https://www.sysmocom.de/jobs/ -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
35
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace