- baseband-devel - lists.osmocom.org

Re: Creating a real usable phone using OsmocomBB
by msokolov＠ivan.Harhan.ORG 12 Dec '11

12 Dec '11

Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> wrote: > That's exactly what I was thinking about, since running the layer23 on the > Application CPU is not a so good idea, it renders the phone usable only for a > small period of time(since,in that configuration, you cannot suspend the AP > CPU because it has to run the telephony code). It's obvious that running layer23 on the AP is a *terrible* idea. It needs to move into the Calypso (or other BP) before there can be any serious thought of OsmocomBB truly replacing the existing proprietary BP code. However, my own skill & knowledge level is nowhere close to what would be needed for that job. But I was thinking of taking the current sorry state of things (layer23 external to the BP) and making it run on a self-contained GTA02: have the Samsung AP run layer23 instead of acting as a pass- through to a PC, then add some UI to it: the very same UI I wanted to implement in the first place before I got sidetracked to the baseband issues. The result of that would be having the GTA02 act as a "normal" feature phone in every way except for draining the battery in a couple of hours while doing nothing. The last aspect would make it rather unusable practically (unless perhaps one replaces the standard Li-ion battery with an automotive-sized lead-acid one), but it would be a tangible hands-on "teaser" of what would be possible if someone with the necessary knowledge and skills took the bother to redesign the code (move layer23 into the Calypso) such that proper PM could be implemented. > Why is AT bad? what other protocol do you propose? What Peter said: : Um, no, it's the other way around. AT is 30 years of horrible. If I were able to lay my hands on some source for an *existing* implementation of the AT command interface on the BP side, I would have no problem with implementing it on the AP side in my UI. But if I have to write the code from scratch on both sides of the interface, I'll probably implement some ad hoc protocol of my own rather than attempt to implement the "standard" one and get it wrong. MS

1 0

Trouble with C117 while using osmocon
by Sreeraj R 11 Dec '11

11 Dec '11

Hi all, I am just a beginner and is using the following hardware Phone : C117 Serial Adapter : CP2102 based The propt message that I am getting is different compared to that mentioned in the wiki (http://bb.osmocom.org/trac/wiki/CompalRamloader) Command: ./osmocon -d t -p /dev/ttyUSB0 -m c123 ../../target/firmware/board/compal_e88/loader.compalram.bin Gives me the following data {00,f1,01,72,82,bf,7d,fd,7f,00,a6,51,d2,51,0a,3a,02,4d,a3,a3,da,00,00} Entire log after short power button key press is http://pastebin.com/AqcNm6dq. Can anyone give some pointers, or did I go wrong somewhere. The wiki specifies C117 board is similar to C123. regards Sreeraj R

2 1

Re: gnuarm version
by R M 10 Dec '11

10 Dec '11

Hi, I am using this version of GNU Arm. http://www.gnuarm.com/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.exe Regards, RM On 12/4/11, Juantxi <juantxipazos(a)yahoo.es> wrote: > > Hello, what version of gnuarm uses? > thank >

1 0

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

05 Dec '11

Hi! Thinking a bit more about timing, it seems that the second half of March is a good idea. April is a bad idea, at least for the first two weeks, as this is easter holiday time in a lot of German states. This will cause lots of tourists, as well as full hotels, trains, flights, etc. So I'd propose something like four days in the second half of march. Should we try to overlap/extend a weekend? I guess this would help people with e regular dayjob, as not as many holidays would be required. If there are no objections in the next 48 hours, I will talk to C-Base about availability during that timeframe. 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)

3 4

Script for parsing boot loader into COFF
by R M 03 Dec '11

03 Dec '11

Hi, Is there a script for parsing the boot loader code into a COFF format so that it can be loaded into IDA? Regards, RM

1 0

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