baseband-devel January 2011

baseband-devel@lists.osmocom.org

71 participants
98 discussions

Start a nNew thread

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

7 7

Receiving on TS=1 ?
by Sylvain Munaut 20 Jul '12

20 Jul '12

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

2 5

Use OsmocomBB as OpenBTS / airprobe clock generator
by Harald Welte 15 Mar '12

15 Mar '12

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

8 17

Linux + u-boot port to MT6235
by Marcin Mielczarczyk 07 Jan '12

07 Jan '12

Hi All! That's true, I managed to run U-Boot on MT6235, but linux kernel is not fully functional yet (it's fresh stuff as I managed to ran it on Tuesday and then I was off to conference). For MT6235 development I chose Sciphone G2, which is pretty cheap. After some time I managed to download code to SRAM (just 64KB) using MTK's FlashTool. MTK FlashTool communicates over UART directly with MT6235 bootloader and sends its own chunk of code (about 58KB) which is executed in SRAM and communicates with FlashTool. I found on pudn.com some pack to customize code loaded by FlashTool, thanks to which I could download my own code to SRAM (without JTAG). The problem was that it had to be linked with some security libraries which occupied about 56KB and not much memory left for my own code. Then I decided to try find JTAG pins to get all control on MT6235. That took me sometime, but finally I succeeded. The other bigger issue was initializing DRAM controller to be able to download bigger code (linux kernel + uboot) to external RAM. In sciphone there is problem that all interesting chips are under metal shield which is pretty havily soldered. In this case I couldn't read what kind of RAM memory is mounted without destroying the board (I don't have such soldering machine which could unsolder so big metal shield). Thanks to JTAG I could attach to target and then dump DRAM controller registers from processor running MTK's software, but setting these values after processor start and configuration of PLL didn't work. I decided to disassemble bootloader which could show me how DRAM controller is initialized and how code fron NAND is loaded (to be able to flash U-Boot and kernel to NAND so MT6235 will start my code automatically and I will not have to use JTAG). Currently I have knowledge how internal MT6235 bootloader is loading code from memory during startup and I also extracted procedure of DRAM controller initialization. Thanks to that I'm able to run U-Boot from the very begining of processor startup. The problem is that I have just one piece of Sciphone G2 and I don't want to flash it yet to not break existing code in it. Thanks to running device I'm able to attach with JTAG and check how peripherals are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm not 100% sure if I will flash it back, phone will startup. That's why I bought second piece of Sciphone G2 and should receive it today or on Tuesday (this Monday is holiday in Poland). In this case I'll flash U-Boot to NAND and try to make it working. Then we could load the rest of code from U-Boot (to RAM or NAND over serial). You can see how my setup looks on attached picture. The good thing about it is that the same bootloader is used in MT622x, so it should be fairly easy to do the same on phones based on that SoCs (but unfortuantely it's just ARM7). If it comes to code, of course I can share it on "git.osmocom.org". Currently it's just basic port of U-Boot and not much for linux kernel, but I'm working on this now so I'll push it when it'll be ready. Currently I'm working on driver for NAND memory for U-Boot, so we could flash linux kernel. When that will be ready I'll push the code. Then I'll switch to linux kernel and when it'll be functional I also push the code. At this stage you will not need to have JTAG and you could load the code over serial in U-Boot. If it comes to GSM I didn't work with it before. I actualy worked 6 months in L2/3 team for LTE (on RRC) but it's different story. That could be really outstanding thing if we could run first phone ever with whole code open (from BB up to APP). BR, Marcin

13 37

Problems while building osmocomBB
by Begerad Stefan 28 Oct '11

28 Oct '11

Hi guys, I dunno if that is the right place for my concern about building the osmocomBB source. Here is what I already have done: - downloading the sources for osmocomBB and GNU toolchain for ARM, - setting the PATH for the arm-elf-* executables, - calling make in the src directory. Now, this appears as response of the make command in the terminal: cd shared/libosmocore/build-host && ../configure configure: error: cannot find install-sh, install.sh, or shtool in ".." "../.." "../../.." make: *** [shared/libosmocore/build-host/Makefile] Error 1. If you need details about my system, you can look at the following snippet from the config.log file: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by libosmocore configure UNKNOWN, which was generated by GNU Autoconf 2.65. Invocation command line was $ ../configure ## --------- ## ## Platform. ## ## --------- ## hostname = ubuntu-stefan uname -m = x86_64 uname -r = 2.6.32-24-generic uname -s = Linux uname -v = #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games PATH: /home/stefan/osmocomBB/gnuarm-4.0.2/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2032: error: cannot find install-sh, install.sh, or shtool in ".." "../.." "../../..". So, I would be very glad, if someone could give me a hint to solve the problem. Thank you in advance. Regards, begy

2 2

buzzer driver
by José Luis Pereira 24 Apr '11

24 Apr '11

Hi all, my name is Jose Pereira, and i'm very interested in helping you with some code! I've wrote the buzzer driver for calypso, not so sure if will help you of anything, but was just for experimenting :) Anyway, i send the patch in attachement. The interface can be simply #include <calypso/buzzer.h> buzzer_mode_pwt(1); buzzer_volume(40); buzzer_note(NOTE(NOTE_E,OCTAVE_5)); Please let me know what do you think of the code, and in what way i can further help. Best regards, -- José Pereira http://onaips.blogspot.com

2 1

Linux + u-boot port to MT6235
by Harald Welte 22 Mar '11

22 Mar '11

Hi All! At my OpenBSC / OsmocomBB talk here at the Embedded Linux Conference Europe, one of the attendees (Marcin, see Cc) came to me after the talk and told me he had recently done a u-boot and Linux kernel port to the MT6235 (that's the ARM926 based chipsets found in the touchscreen MTK phones). He said he has no understanding of GSM or the existing MTK firmware, but is interested in working together with us to try to make the GSM part work. I think that chipset is very intesting, as we could implement the layer1 inside the Linux kernel (and submit that mainline, yay!) and run our layer2 and layer3 implementations as userspace processes on the Linux system, together with the user interface. The performance of those devices should be somewhere between the Openmoko GTA01 and GTA02, and the GSM stack is certainly not going to eat away a lot of the CPU either. I have asked Marcin to write mail to the OsmocomBB mailing list on where we can find the code. He has so far downloaded the code using JTAG. Combining his code with our ramloader might remove that JTAG dependency... Marcin: if you want to push your u-boot / kernel to git.osmocom.org, or want a separate trac installation for your mtk-linux work, pleaes let me know, I'd be happy to host that. Regards, 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)

2 1

mobile: config file in /etc/osmocom/osmocom.cfg
by Harald Welte 02 Mar '11

02 Mar '11

Hi all, I would like to propose moving the config file into something like ~/.osmocom/ and not put it in a system wide directory. The path in /etc/ is the only part of OsmocomBB that requires root privileges, and I don't really think that in a case of multiple users you would want to e.g. share stuff like the IMSI / Ki anyway. What do you think? -- - 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)

3 4

FCCH and SCH
by list_mailing 10 Feb '11

10 Feb '11

Hello, I'm newbie to osmocomm and GSM too....I'm studying the protocol and the source code...but I have many doubts...the first one is the following: 1. Which are the routines handling FCCH and SCH in osmocom source code? 2. When I load layer1 firmware and load mobile app, FCCH and SCH are automatically handled by this application? Sorry if my questions are stupid for you, but it's a litlle bit complicate moving in the code, above all for a newbie. Thanks in advance. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/FCCH-and-SCH-tp2363201p2363201.h… Sent from the baseband-devel mailing list archive at Nabble.com.

2 2

thinking about the sim
by Sébastien Lorquet 07 Feb '11

07 Feb '11

Hello, I was walking through trac while I came across this file: http://bb.osmocom.org/trac/browser/src/host/layer23/src/common/sim.c I see here: 183 /* send APDU to card reader */ 184 static int sim_apdu_send(struct osmocom_ms *ms, uint8_t *data, uint16_t length) 185 { 186 LOGP(DSIM, LOGL_INFO, "sending APDU (class 0x%02x, ins 0x%02x)\n", 187 data[0], data[1]); 188 l1ctl_tx_sim_req(ms, data, length); 189 return 0; 190 } ohoh, that's hardcoded. If we would like to have a software SIM, a SIM in a card reader on the PC, or a real sim in the MS, I think this would this be the correct place to plug a modular sim implementation. I mean something that looks like: struct osmocom_sim_ops { int (*sim_apdu_init)(.....); int (*sim_apdu_fini)(.....); void (*sim_op_reset)(.....); void (*sim_apdu_send)(.....); void (*sim_response_callback)(.....); }; void ms_register_sim_driver(struct osmocom_ms *ms, struct osmocom_sim_ops *ops); this could be a part of struct osmocom_ms. I would be easy to have 3 implementations: -sim in the mobile, using the current calls 'l1ctl_tx_sim_req' 'l1ctl_tx_sim_conf' -sim in PCSC using pcsclite or winscard, and a command-line option to select the reader (by index, by name, or first reader with a card inside for simple setups) -virtual sim using pure software What do you think about this? Regards Sebastien

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel January 2011