baseband-devel November 2011

baseband-devel@lists.osmocom.org

29 participants
40 discussions

26 Nov '11

Hi, Its better you send the mail to the list rather than just to me. In that way you get more help. I have built osmocom using cygwin. But I am unable to get the code downloaded into the phone. I am facing timing issues. I am still looking into the issue though. The instructions to install cygwin are found at: http://cygwin.com/. By default cygwin installs just the basic tools. Once you have installed the basic tools, you have to run the installer again to get the tools required for building osmocom. The tools required are given in the Wiki at this link: http://bb.osmocom.org/trac/wiki/GettingStarted. Once you have done that you need to install gnu arm. In the same wiki you have the links to download the cygwin version of GNU Arm. The ftdi cable I use is at this link:http://www.sparkfun.com/products/8772. Regards, RM On 11/24/11, Juantxi <juantxipazos(a)yahoo.es> wrote: > hello, > osmocom-bb got compile using cygwin? > packages could tell me that you downloaded? > which cable did you use? > > I am interested in doing > thanks >

1 0

Bug in gprs decode software
by Dario Lombardo 25 Nov '11

25 Nov '11

Hi guys Today I'm experiencing a bug in the gprs decode software. In rlcmac.c:190, when li_off and f->len get invalid values, we have a buffer overflow in the mempy(). In my case f->len=15, li_off=135. The really stupid patch to avoid it is below: simply jumps the case. I'm not able to investigate why li_off becames greater than f->len, causing the crash. Maybe a check should added. Have some other seen this crash? diff --git a/rlcmac.c b/rlcmac.c index eea02ce..d76a8d6 100644 --- a/rlcmac.c +++ b/rlcmac.c @@ -187,11 +187,14 @@ void process_blocks(struct gprs_tbf *t, int ul) print_pkt(llc_data, llc_len); fflush(stdout); } - memcpy(llc_data, &f->data[li_off], f->len-li_off); - llc_len = f->len - li_off; - llc_first_bsn = bsn; - llc_last_bsn = bsn; - t->start_bsn = bsn; + + if (f->len > li_off && f->len-li_off > 65536) { + memcpy(llc_data, &f->data[li_off], f->len-li_off); + llc_len = f->len - li_off; + llc_first_bsn = bsn; + llc_last_bsn = bsn; + t->start_bsn = bsn; + } } }

1 1

[PATCH 0/0] firmware janitor work to reduce compiler warnings
by Alexander Huemer 24 Nov '11

24 Nov '11

This patch series reduces the number of warnings emitted during firmware compilation. No functional changes. The patches could NOT be TESTED, so please try them before merging. Kind regards, -Alexander Huemer

5 23

[PATCH] rf: dereference pointer
by Alexander Huemer 21 Nov '11

21 Nov '11

--- src/target/firmware/rf/mt6139.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/target/firmware/rf/mt6139.c b/src/target/firmware/rf/mt6139.c index a9a6d32..d48e652 100644 --- a/src/target/firmware/rf/mt6139.c +++ b/src/target/firmware/rf/mt6139.c @@ -39,13 +39,13 @@ static void mt6139_compute_pll(uint32_t f_vco_100khz, /* To compute Nint, we assume Nfrac is zero */ *nint = (fvco_100khz / (10 * 2 * 26)) - (0 / 130); - if (nint > 127) + if (*nint > 127) printf("VCO Frequency %u kHz is out of spec\n", f_vco_100khz); /* Compute Nfract using the pre-computed Nint */ /* Nfrac = ( (Fvco/2*26) - Nint) * 130 */ /* Nfrac = ( (Fvco*130)/(2*26) - (Nint * 130) */ - *nfrac = (f_vco_100khz*130)/(52*10) - (nint * 130); + *nfrac = (f_vco_100khz*130)/(52*10) - (*nint * 130); } /* Set ARFCN. Takes 2 reg_write, i.e. 8 TPU instructions */ -- 1.7.8.rc1

3 3

OsmocomBB on Motorola W220
by Alan Carvalho de Assis 20 Nov '11

20 Nov '11

Hi all, I want to know if someone here already tried osmocombb on Motorola W220? This cell phone is powered by D751749ZPH, but at least my model (W220 E2) doesn't communicate with "osmocon". The problem is not serial cable because it work correctly with C115. After some search I discovered the uart is disabled by software, some firmware version let users to enable it after entering on engineering mode (*#**372#), unfortunately my firmware doesn't have this option at eng. mode. You can see a picture of my W220 board here: http://acassis.files.wordpress.com/2011/11/sam_1634.jpg If someone has some idea for an alternative option (JTAG?) please tell me. BR, Alan

2 2

Re: Diff between TWL3014 and TWL3025
by msokolov＠ivan.Harhan.ORG 19 Nov '11

19 Nov '11

Sylvain Munaut <246tnt(a)gmail.com> wrote: > Google for TWL3016 SWCS010 and check for yourself Thanks once again! OK, so TWL3016 *is* Syren indeed, and it does have additional features over Iota. But EDGE modulation support isn't one of them. If my reading of the doc is correct, the additional features of Syren over Iota are I2S audio, high voltage charger input and the USB regulator support. Does this agree with your reading? MS

1 0

Re: Diff between TWL3014 and TWL3025
by msokolov＠ivan.Harhan.ORG 19 Nov '11

19 Nov '11

Steve Markgraf <steve(a)steve-m.de> wrote: > Search Google for "TWL3025 SWRS021", last hit. Thanks, got it. (In my case it was the middle of the 3 results rather than the last.) I wonder about all these Chinese websites... It looks like they have a healthier attitude about sharing this kind of stuff than the Westerners do. So far we've known about 52rd.com hosting "contraband" phone handset chip documents, and now we know there's also baisi.net... But I find it strange that only PDF datasheets and PPT presentations have been found so far, and not, for example, any of the source/object-mix packages that must have been given for the firmware side of things by TI et al to the same folks (phone makers?) to whom they've given the chip docs. NDA etc issues ought to be the same... Or maybe I just haven't been looking hard enough... Would anyone here perchance happen to have a link to some place on one of those Chinese sites that has the original FW source (or semi-source, as in bits of source mixed with binary object blobs) for the Leonardo reference board or for some other Calypso-based HW version that's more readily available (as in HW availability) than the famous TSM30 version? (I realize that it would never be acceptable to use any such code in a Western FOSS project like OsmocomBB, but I would still *love* to take a peek at the original code for some phone whose HW is better understood and/or more readily available than the TSM30.) > Both TWL3014 and TWL3025 are Iota, TWL3016 is Syren. Hmm. I agree that TWL3025 must be some equivalent Iota variant, and I think you are right about TWL3016 being Syren: the Rita_intro.pdf document in my collection (see my FTP site) says "It is compatible with Iota (TWL3014) and Syren (TWL3016) ABB chips". However, the Iota_intro.pdf document (same FTP site) shows the Nausica->Iota->Syren evolutionary line and lists Syren as EDGE-capable. But Sylvain says TWL3016 doesn't do EDGE either. Hmm. Are you sure? MS

2 1

Re: Diff between TWL3014 and TWL3025
by msokolov＠ivan.Harhan.ORG 18 Nov '11

18 Nov '11

Steve Markgraf <steve(a)steve-m.de> wrote: > Well, some time ago I diffed the TWL3014 and TWL3025 datasheets, Where did you find the TWL3025 datasheet? Wading through 52rd.com, or is there some other source I'm unaware of? > there is no technical difference at all (only 3014 replaced with 3025, > and some minor formatting changes). > [...] > I suspect that TI renamed > the chip because of some changes in the manufacturing process. Hmm, interesting. > Given that both chips work fine with osmocom (with the same revision of > DSP rom code on the Calypso side of things), What OsmocomBB-supported phones use TWL3014? Sylvain Munaut <246tnt(a)gmail.com> wrote: > > supposedly called Syren rather than Iota and supports EDGE modulation. > No it doesn't. > [...] > > Is it a Iota variant or a Syren variant? > I think they're all called "Iota" that's a generic designation for the ABB. I believe that the codenames refer to specific generations for each function, rather than to functions like DBB/ABB/RF. For example, it seems that Calypso succeeded Hercules in the DBB role, and Rita succeeded Clara in the RF role. I remember seeing somewhere that Iota's successor was/is Syren, whereas its predecessor in the ABB role was Nausica. But if TWL3016 and TWL3025 are both Iotas, which chip is then Syren? Does anyone know? MS

3 2

Diff between TWL3014 and TWL3025
by msokolov＠ivan.Harhan.ORG 18 Nov '11

18 Nov '11

Hello GSM BB hackers, I wonder, would anyone here happen to know what are the main diffs between the TWL3014 and TWL3025 ABB chips? TWL3025 is the chip that appears to be used in most of the phones currently supported by OsmocomBB, but the presumably older TWL3014 is the only one for which we have docs as part of the Calypso and Leonardo documentation set at: ftp://ifctfvax.Harhan.ORG/pub/GSM/Calypso (The above FTP server is mine, but the content originates from the 52rd.com Chinese forum linked to from some of the OsmocomBB wiki pages.) Hence me wondering if anyone here knows what the actual differences are... I also recall seeing somewhere (don't remember where) that Iota strictly means TWL3014, and that its successor (TWL3016?) is supposedly called Syren rather than Iota and supports EDGE modulation. If that is true, where does the TWL3025 fit into that picture then? Is it a Iota variant or a Syren variant? It ought to be newer than TWL3016, right? Does that mean it ought to support EDGE? If so, what stands in the way of EDGE support in phones like GTA02 that use the TWL3025 ABB? Lack of Calypso DSP support? Or an RF front-end that isn't compatible with EDGE modulation? Or is TWL3025 a step backward from TWL3016, without EDGE support? If so, would anyone happen to know what its raison-d'etre is? What does it offer over the TWL3014? Just wondering... MS

3 2

Compile with DEBUG fail / i2c.c
by Stefan Mandl 15 Nov '11

15 Nov '11

Hello all, if you compile with #ifdef DEBUG, 2 litte typo errors came up... Regrads from stefan my patch... --- a/src/target/firmware/calypso/i2c.c +++ b/src/target/firmware/calypso/i2c.c @@ -67,7 +67,7 @@ int i2c_write(uint8_t chip, uint32_t addr, int alen, const uint8_t *buffer, int if (len > 16) return -1; - printd("i2c_write(chip=0x%02u, addr=0x%02u): ", chip, addr) + printd("i2c_write(chip=0x%02u, addr=0x%02u): ", chip, addr); writeb(chip & 0x3f, I2C_REG(DEVICE_REG)); writeb(addr & 0xff, I2C_REG(ADDRESS_REG)); @@ -91,7 +91,7 @@ int i2c_write(uint8_t chip, uint32_t addr, int alen, const uint8_t *buffer, int /* wait until transfer completes */ while (1) { uint8_t reg = readb(I2C_REG(STATUS_ACTIVITY_REG)); - printd("I2C Status: 0x%02x\n", rerg & 0xf); + printd("I2C Status: 0x%02x\n", reg & 0xf); if (!(reg & I2C_STATUS_IDLE)) // 0: idle 1: not idle break;

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel November 2011