baseband-devel December 2010

baseband-devel@lists.osmocom.org

30 participants
31 discussions

by 麦田守望

Hello everybody you may have USRP ＵＳＥ　ＭＴＫ　ｃｈｉｐ　ｐｈｏｎｅ　ｆｏｒ　ＤＩＹ　ｙｏｕｒｓｅｌｆ　ＢＴＳ　Simple　ａｎｄ　Practical　　ｉ　ｆｉｎｄ　Developmentｅｒ　Contact　ｍｅ

14 years, 10 months

MTK chip for GSM USRP

by 麦田守望

Hello everybody I want to develop USB Interface USRP Use MTK 6218 chip, But no Firmware Source Code 6218 is ARM Core 'USE it is a GSM Way of USRP .Friends if you Have to know Please contact me

14 years, 10 months

Qualcomm documentation

by Andreas Galauner

Hello everybody, last year I stumbled upon a PDF which describes all registers inside the Qualcomm MSM7200 series chipset. I now got a new mobile phone and remembered about that document because wanted to play a bit with my old one (HTC Magic/Sapphire/G2/Ion). I googled a few hours now and found several documents from Qualcomm, but I just found a whole svn repository full of Documentation [1]. Those Qualcomm chipsets are particularly interesting, because, due to Android, there already is a Linux kernel for the ARM11 core available. The missing part is a free implementation of the ARM9 baseband. My next goal is, as soon as I managed to solder cables to the JTAG pins covered in epoxy, to get own code running on the ARM9. I don't know how hard this will get, because this chipset has several security features like signature checking of code, fusebits for security configuration etc., but I will give it a try. JTAG definitely is still activated, because several people developed a method to unbrick their phones in case they have a bad ARM11 bootloader. And even if there is no chance to get own code running right away, I'm pretty certain that there somewhere is a buffer overflow which is exploitable. Either inside the baseband itself or in the serial console command parser of the early bootloaders provided by the OEM (OEMSBL). Time will tell. I hope I've got something to show you at the 27C3. My problem is that I don't have enough experience and knowledge about GSM yet to estimate if all this documentation is sufficient to implement a real baseband software on this chipset. If it's not, I think it's pointless to invest several days/nights of work to get own code running. Maybe somebody of you can have a quick look over the repository and the documents? Thanks, Andy [1]: http://code.google.com/p/ptwcdma/source/browse/

14 years, 10 months

Osmocom SIMtrace

by Simon Barnett

Hi All, I'm not 100% sure this is the right place to post this really, maybe someone can point me in the right direction if I'm in the wrong place. I'm trying to build the Osmocom SIMtrace firmware, but so far I'm not having much luck When I try to make it I get the following output: - make -f Makefile.dfu BOARD=OLIMEX -------- begin (mode: RUN_FROM_ROM) -------- arm-elf-gcc (GCC) 4.0.2 Copyright © 2005 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. scripts/mkcompile_h > include/compile.h svn: '.' is not a working copy svn: warning: '.' is not a working copy make: *** No rule to make target `src/simtrace/usb_strings_dfu.txt', needed by `src/simtrace/usb_strings_dfu.h'. Stop. Has anyone got any ideas how I might be able to fix this? Thanks, Simon

14 years, 10 months

Sciphone's Versions and European Shops

by luca bongiorni

Hi mates, i was thinking to start to work also on Sciphone and starting to learn as much as i can and contribute to the community (even if actually i'm a noob of phone firmwares, i worked only on MIPS router firmwares ). Have you some usefull books/wiki/etc to start on? These are the 3 versions identified of Sciphone: HY27XS08121M - 512Mb (64MB) NAND + 32MB RAM HY27XA081G1M - 1Gb (128MB) NAND + 32MB RAM TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM How i could ask to sellers for the best version? (TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM) Do you know an european shop where i can find it? Thankyou for attention folks Regards Luca

14 years, 10 months

[ADM] Please try to avoid merges in the git tree

by Harald Welte

Hi all, this is just a general request to everyone with git commit access on the OpenBSC / Osmocom repositories. I would appreciate to restrict the use of 'git merge' to the absolute minimum neccessarry, as it makes the commitlog and timeline much harder to understand. If you're working on some private branch on a particular feature, please rebase that private branch on current master before pushing the changes. Thanks! -- - 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)

14 years, 10 months

[PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X.

by David Wilson

--- src/host/layer23/src/common/l1l2_interface.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index e72b86e..08ef7be 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -118,9 +118,10 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) local.sun_path[sizeof(local.sun_path) - 1] = '\0'; rc = connect(ms->l2_wq.bfd.fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local)); if (rc < 0) { - fprintf(stderr, "Failed to connect to '%s'.\n", local.sun_path); + fprintf(stderr, "Failed to connect to '%s': %s\n", local.sun_path, + strerror(errno)); close(ms->l2_wq.bfd.fd); return rc; } -- 1.7.3.2 -- Computers are useless. They can only give you answers. -- Pablo Picasso

14 years, 10 months

MT6235/6140 and MT6516?

by Duane Lew

Dear Members, I incidentally see your development of linux drivers for MT6235/6140 chipset(the sciphone G2), and wanna share my 50 cents: The year 2009 released AP+BB monolithic chip MT6156 from mediatek is an ARM9 AP + ARM7 BB (the old MT6235 is ARM9 AP, MT6140 is ARM7 BB), considering the timeline of mediatek processors, it should be conjectured that MT6516 is a combination of these two chips. They already have Windows mobile 6.5 drivers mature for MT6516, and they have android drivers (not only driver but the whole system image), which might be an important referenece for developing MT6235 linux drivers. So I believe it's a good idea to ask MTK for its MT6516 linux driver and see what can be ported. Best for all, Duane

14 years, 10 months

[PATCH] protocol: typofix for gsm_03_41.h

by Hermann Gausterer

On Tue, Dec 07, 2010 at 08:16:06PM +0200, Alex Badea wrote: > On 12/07/2010 06:36 PM, Hermann Gausterer wrote: > >Small typo in the second Serial Number Octet > > > >Signed-off-by: Hermann Gausterer<libosmocore-2010(a)mrq1.org> > > Good catch, thanks! > > You should send this patch to baseband-devel(a)lists.osmocom.org such > that one of the maintainers can apply it. > > Thanks, > Alex

14 years, 10 months

Sciphone G2 (MT6235) status

by Marcin.Mielczarczyk＠tieto.com

Hi list, Last days I was focused on getting self-built code running from NAND memory and finally I got it working. You can find short demo which actually covers all the functionality which is currently working on Sciphone: http://www.youtube.com/watch?v=w_Iwsckm7Ko Here is the list of functionalities which are already working: * NAND memory driver with HW ECC control and MTK's ECC layout (ECC layout is important for loading SPL, creating dumps of firmware and restoring it). NAND driver also supports all the NAND memories found so far on Sciphone G2 (small page and large page). * SD/MMC card support * LCD driver (automatically detects LCD controller, so far identified two different LCD controllers mounted in G2: ILI9331 and ILI9325) * tool for creating bootable image from given binary file (should work on all MT62xx chips). It doesn't need to be SPL (from U-Boot), it can be self-built binary which will be run by IPL on the phone (not bigger than 64kB). * automatic detection of RAM memory in SPL (two configurations checked) - this will be added by Steve to osmocon loader as well * BBT and ENV can be saved in NAND (BBT in NAND is disabled by default, as deletes last two NAND blocks, and most people are running from RAM) I also updated wiki with informations about new features added: http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 Open issues: * LCD controller is using the same data lines as NFI (NAND) controller. Currently it's not possible to use NAND when LCD is enabled. * vibrator in SPL code - vibrator will be turned on in SPL when it'll start reading NAND and turned off when it'll finish, thanks to that user will know that SPL code has started (short code which doesn't change SPL size). * boot process from NAND has been tested only on small page NAND device - I'll create dump of my second phone and try this process on large page NAND device as well I recommend to create full NAND dump before playing with new software. There is already driver for NAND running and you can erase/write NAND easily by mistake. I turned on define CONFIG_ENV_IS_IN_NAND, which will not erase/write NAND at start, but when you execute "saveenv" command it'll do so. Please, make NAND dump first. The problem with NAND dump is that I haven't found built-in functionality in U-Boot that sends dump of RAM memory (where NAND will be read) to PC/SD card. Dump also has to be created in chunks, as there is less RAM memory than NAND. I'm planning to create dump/restore commands which will save/restore dumps using SD card, but I didn't start it yet. Currently the easiest way is to create dump in FlashTool. I checked that restoring of phone using dump created in FlashTool works, so going back to previous firmware is possible. Unfortunatelly code for LCD driver is not yet in git as my coleague didn't manage to finish it today. Hopefully it'll be available during weekend or beginning next week. Now I'm going to switch to Linux kernel side and start writing drivers there... Other good new is that Andrew has reported last week that he successfully run our code on E1000 chinese phone which is also based on MT6235. There was no need to make any changes. Here is how E1000 phone looks like: http://triray.en.made-in-china.com/product/kbYJeomynHhs/China-N97-WiFi-Java… BR, Marcin

14 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel December 2010