baseband-devel November 2011

baseband-devel@lists.osmocom.org

29 participants
40 discussions

osmocombb and usrp
by Paul Lambert 14 Feb '12

14 Feb '12

Hello, I have a ursp1 working fine and I want to use my c123 to conenct to it with osmocombb. Now I face some problems. First of all I have no sim, so I do: sim testcard 1 001 01 The usrp runs a testnetwork (001 01) I don't know how I can associate with the usrp. I tried: network search (lot of output and also my testnet) network show (nothing happens) network select 1 001 01: Network not in list! Any idea what I'm doing wrong? Would be really Cool if i could use opensource only. With best regards, Paul

3 3

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

R: GPRS decode tutorial
by Luca Bongiorni 02 Jan '12

02 Jan '12

Hi Dario, i suggest you to download the last Sylvain's burst_ind, because is improved of some features and patch it manually with Nohl's patch. Then you will be able to dump the bursts using ccch_scan, instead of layer23. Cheers, Luca > Can someone drive me to the right direction? P.S: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/1754

3 2

RFC: Osmocom developer workshop 2012
by Harald Welte 14 Dec '11

14 Dec '11

<DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Hi all, this idea has been around for quite some time, and for 2012 I really want to turn it into reality: I'd like to have a Osmocom developer workshop The idea here is to get all the active contributors of the project together for a couple of days (maybe 2-4 days), in order to exchange ideas, get to know each other better and last but not least work together on ironing out some of the more difficult issues. * City: Regarding the location: I think for me it is only possible to organize it if it is to be held in Berlin. I'mn happy if somebody else wants to host it at some other location, but then that person would also have to take care of local organization. Berlin also has good train and flight connections, which is definitely a plus. * Venue: If it is in Berlin, we might consider talking with c-base or Raumfahrtagentur as possible venues. * Date: Regarding a proposed date, I'm completely open for suggestions. Of course there shouldn't be any overlap with other major FOSS or Sescurity related conferences, and it should also not coincide with major public holidays, as that only makes travel + accomodation more expensive. * Funding: As we don't have that many commercial users of Osmocom projects, getting funding for e.g. travel / accomodation is probably going to be difficult. We can ask the "usual suspects" among those commercial users we know,, but I guess it will only be possible in exceptional cases to provide that kind of funding. Any ideas / comments / feedback is much appreciated. If somebody has a particular suggestion. <DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Cheers, 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 2

MTK and Infineon-based phones
by Martin Hinner 28 Nov '11

28 Nov '11

Hi Marcin, On Sun, Nov 27, 2011 at 1:17 AM, Marcin Mielczarczyk <marcin.mielczarczyk(a)gmail.com> wrote: > Note, that on the market there is much more Mediatek phones based on ARM7 > (MT622x) than on ARM9 (MT623x). You are right, it makes sense. My mistake. I was only working with flash dumps so far... I have spent some time analyzing mtk-phone project. There is a lot of files missing, but the situation is not so bad. My feeling is that some of the files were simply deleted from the project... (interrupted upload?) I made a list of all files needed to link binary image (from .lis file). Then I did: find . -name '*.c' Then I ran ar l on al mtk-lib .lib files (these can be quite easily disassembled). And finally diff helped to find what is missing... We're missing only these files (no .obj in .lib or .c is present in the project): -lic.c -drvflash.c -l1c_trace.c -l1d2_trace.c -l1d3_trace.c -l1d_edge_trace.c -l1d_trace.c -l1sc_trace.c -l1trc.c -l4drv.c -sst_decrypt.c -sst_intrctrl.c -sst_secure.c -trcmod.c I think none of these are needed for our stuff. Then we are missing .c files, but have .obj in .lib (only important files) dp_engine.lib: awb_bitstream.c (unknown for what is this) dsp_ram.lib: ddload.c dsp_ram.lib: dsp_ptch_6223.c (we can get this from binary) dsp_ram.lib: idma.c l1.lib: l1csm.c l1.lib: l1dsm.c l1.lib: m*.c (it's a lot of files !!!!!!!!!!!!) In fact this is end of all important routines... Tracing functions: l1.lib: l1i_amr_trace.c l1.lib: l1i_cs_trace.c l1.lib: l1sc_trace.c l1.lib: l1t_amr_trace.c l1.lib: l1c3_trace.c l1.lib: l1c4_trace.c l1.lib: l1c_csd_trace.c l1.lib: l1c_trace.c l1.lib: l1d2_trace.c l1.lib: l1d3_trace.c l1.lib: l1d_edge_trace.c l1.lib: l1d_trace.c l1.lib: rftool_gsm.c (shows how to call various functions) Only for testing: l1.lib: l1tst_afc.c l1.lib: l1tst_agc.c l1.lib: l1tst_cfg.c l1.lib: l1tst_cont.c l1.lib: l1tst_fcb.c l1.lib: l1tst_fhc.c l1.lib: l1tst_nbtx.c l1.lib: l1tst_pm.c l1.lib: l1tst_ul.c I have already tried to disassemble some of them and it all makes sense, most of functions are very simple and some files are not even needed. My feeling is that we have all needed to understand the DSP functionality / L1 part of the ARM code! The biggest problem is that m*.c files depend on hardware (a lot of #ifdefs), so this needs to be analyzed on firmware downloaded from hardware. [ Question: why such cryptic names such as m12170.c ? ] I also have list of functions in those files, if anyone's interested in helping me with locating what is important and what is not... (34 kB). Martin

2 2

MTK and Infineon-based phones
by Martin Hinner 27 Nov '11

27 Nov '11

Hi, I spent a few hours today looking at CCC presentations and osmocom code. Good and interesting work! I have a couple of questions... This is my first experience with GSM phones reverse engineering, so sorry if I am wrong, but it seems to be quite difficult for me to obtain four Calypso-based phones (yes, I know I can order them from webshop for a few euros, but I will need more of them if my experiments are successfull). On the other hand, I have access to very cheap phones using Infineon PMB7880 (C166 + DSP) or MTK (ARM9) chipsets. Currently, I do have some information (datasheet&code) for MTK platform, and I see there is implementation of "secondary bootloader" for these phones, but no layer1 yet. I also have very basic documentation of Infineon SoC, plus I have knowledge of the C166 code and I can very easily play with it (reverse engineer firmware & assemble my own code). Is it feasible to create layer1 implementation for Infineon and/or MTK? Is there anyone willing to help with this? Here are my additional questions related to the above question: - Is there any documentation of mask-rom bootloader for Infineon C166 core? - At this moment I do not understand how does the DSP on the PMB7880 work, if RF part is accessible from both DSP and C166 or just the DSP. - How is it with Infineon DSP code, is it present in flash memory, or is it ROM-only thing? Anyone has the code dump? - Is anyone (who has experience with Calypso layer1) willing to help with implementing the same on Infineon or MTK platform? - If anyone has any resources for these two plaforms, I would be grateful if you can send them to me. I will add that I have spent many many nights disassembling car control units using Infineon/Siemens C166 core (since 2002?), so Infineon platform is very attractive for me (the flash is only 2MB for some phones, it's easy to read code, etc...). Thanks, Martin

6 12

[PATCH] i2c: fix maximum address an I2C chip can assign
by Alan Carvalho de Assis 27 Nov '11

27 Nov '11

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

2 1

RFC Wiki re-org of bb.osmocom.org
by Holger Hans Peter Freyther 27 Nov '11

27 Nov '11

Hi, I have recently tried to find some information in our wiki and it was more difficult than I think it should be. I would like to propose and then implement some restructuring. So first of all I think we have good enough content, it is just a matter of structure. Front Page: I would like to have a very simple and structured entry. Mainly pointing to other projects, History, Software and Hardware? Hardware Pages Our hardware pages are mostly the same but actually quite different. I would like to find the following information on each page: - Which firmware/board to use (compal_e88)... - Picture of assembled/disassembled device - Knowledge we have I would like to move all Hardware/MotorolaCXX. The example would be to have hardware/ like this[1] and hardware/MotorolaC118 like this[2]. Software Pages: We have the Getting Started but there appears to be a gap from having a toolchain (or building one) and knowing how the various parts are connected to each other. I have not thought about it too much though. History Pages: I would move some older information in there. E.g. our never started/finished Calypso based design, maybe some parts of the project history. comments? ideas? holger [1] http://wiki.openwrt.org/toh/start#supported.hardware.-.router.type [2] http://wiki.openwrt.org/toh/buffalo/whr-g125

3 2

uplink sniffing
by Lorik Sefaj 26 Nov '11

26 Nov '11

Hi all, Just received my C123 (from http://shop.sysmocom.de/) with filter rework and it works great. I have one problem with the "burst*.dat" files when i do uplink sniffing, basically there are no files produced and when they are produced most of the time they are empty? This doesn't happen when i do downlink sniffing. Is this a stupid question or am I missing something... cheers, L.

4 5

OsmocomBB Bootstrapping
by Kurtis Heimerl 26 Nov '11

26 Nov '11

Hello baseband-devel(a)lists.osmocom.org! I've just started my first OsmocomBB project, using a Motorola V171 and the source code in the main git repository. The short hand version of the story is that we're looking into modifying the GSM MS stack to allow for the BTS to save some power. This is research being done at the University of California, and we're sorta amazed at how wonderful OsmocomBB is for this particular project. Thanks for the work! Progress has generally been good, and I've been able to build and run the "hello world" e99 application. Following that, I've moved onto the mobile app... and run into an issue that I can't seem to resolve by searching your mailing lists. Basically, each individual process runs fine: osmocon installs the compal_e99/layer1.compalram.bin image onto a c155 device mobile connects (though it doesn't see the SIM for some reason...) and the terminal is available and active. I'm not able to do much though, as the MS isn't on yet. Upon turning the MS on, it scans for a while, eventually detecting my own cell tower. Terminal is active during this search. Unfortunately, shortly after detecting and syncing with my tower (ARFCN 51), the terminal freezes. osmocon begins repeating the following error: "Failed to write msg to the socket.." and nothing else moves. Kaput. Terminal does not respond to any messages sent. This is my problem, as I'd like to make a call. PRE-POWERUP mobile: http://pastebin.com/tPm9ux83 POST-POWERUP mobile: http://pastebin.com/fMD1Kth6 osmocon: http://pastebin.com/nc3QGGgD terminal says: kheimerl@darth-maul /tmp $ telnet localhost 4247 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to the OsmocomBB control interface OsmocomBB> % (MS 1) % No service. My intuition is that I've missed setting some key variables in the related configuration files (~/.osmocom/osmocom.cfg, ~/.osmocom/bb/mobile.cfg). though I can't find ANY documentation about what's supposed to be in those things. Any and all help would be appreciated.

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel November 2011