MTK and Infineon-based phones
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
Hi Martin, On Sat, Nov 26, 2011 at 02:03:50AM +0100, Martin Hinner wrote:
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).
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.
the question really is how many of them you need.
On the other hand, I have access to very cheap phones using Infineon PMB7880 (C166 + DSP) or MTK (ARM9) chipsets.
Economically, the question is: * what is the price of the required qty of calypso based phones vs * what is the amount of work needed for porting to MTK Even under the most ideal circumstances, porting the L1 to any new baseband chip architecture is going to be a lot of work. As "ideal circumstances" I count * detailed knowledge about not only the integrated peripherals of the DBB but also register-level documentation of the ABB * detailed knowledge about the shared memory API between DSP-ROM and ARM CPU * no cryptographic verification in bootloader that needs to be broken * a developer who has very strong background on GSM L1 and cellphone hardware * access to measurement devices for MS testing like Racal 6103 Even under such circumstances, I would guess an effort of somewhere between 1 to 2 man-months full-time. As the circumstances are never ideal, it will likely be more effort. Some developers have already put quite a bit of effort into the MTK chipset side, and even though we don't have the register-level data sheets of all of the ABB chips and the DBB data sheets do not cover anything on the details of the DSP/ARM API interface, I think it is the most promising architecture.
Is it feasible to create layer1 implementation for Infineon and/or MTK? Is there anyone willing to help with this?
I think the big issue is availability. The people invovled in OsmocomBB are working on a variety of other projects and protocol stacks (OsmocomGMR, OsmocomTETRA, osmo-bts, etc.) So the big question is: How can you convince anyone from the existing team to contribute to a port to MTK? I think the fact that the code runs well on the Calypso based phones (which are still avialable even in quantity) makes this a bit difficult, as there is no real gain. People generally want to work on creating new functionality, rather than re-creating something that already exists...
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...).
On the other hand: C166 is a one-way road. No new baseband chipsets (even infineon) use them anymore. You need to port all the arm-specific assembly bits in OsmocomBB to the C166 code, etc. MTK is a much more attractive target. More docs, more understanding, more existing code and ARM based. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Harald, On Sat, Nov 26, 2011 at 8:23 AM, Harald Welte <laforge@gnumonks.org> wrote:
Economically, the question is: * what is the price of the required qty of calypso based phones vs * what is the amount of work needed for porting to MTK
yes, you are right. One more thing is in my mind, will China produce enough Calypso-based phones forever? I found 10 MTK-based phones on the market, but not even one TI-based.The problem is that I cannot make any assumptions about amount of work needed to do the l1 task, that's why I asked on the list. [ One more thing, what about making a page on Wiki that lists various phone models with used chips? I can add what I have found so far. ]
Some developers have already put quite a bit of effort into the MTK chipset side, and even though we don't have the register-level data sheets of all of the ABB chips and the DBB data sheets do not cover anything on the details of the DSP/ARM API interface, I think it is the most promising architecture.
Can you point me right direction? I have found some MTK code in git, but there is no documentation at all, etc. Martin
Can you point me right direction? I have found some MTK code in git, but there is no documentation at all, etc.
Osmocom hosts a git-repo for u-boot and kernel. Both reflect the status-quo as far as I know. Same for the wiki-pages on osmocom-bb about Sciphone G2, they should be the status quo. Specs float around the net; the list archive might have some pointers. (Hey, Marcin, where are the barebox-patches BTW ;)) Regards, Wolfram
Hi, On Sat, Nov 26, 2011 at 6:15 PM, Wolfram Sang <wolfram@the-dreams.de> wrote:
Osmocom hosts a git-repo for u-boot and kernel. Both reflect the status-quo as far as I know. Same for the wiki-pages on osmocom-bb about Sciphone G2, they should be the status quo. Specs float around the net;
I meant l1-related code, some parts - for example http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mt62x... or http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/media... ... The kernel for MTK does not seem to have any signs of gsm layer 1 code. Sorry for confusion... Martin
Hi, On 26.11.2011 18:52, Martin Hinner wrote:
I meant l1-related code, some parts - for example
Marcin has implemented some L1 functionality to U-Boot, see his mail back in march: http://lists.osmocom.org/pipermail/baseband-devel/2011-March/001554.html The corresponding commit to uboot-mt623x.git: http://cgit.osmocom.org/cgit/uboot-mt623x/commit/?id=18aa4c659a3e4b1b6262a0f... Regards, Steve
I meant l1-related code, some parts - for example http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mt62x... or http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/media...
This is only used for the loader code, so you can get a bootloader into the phone without JTAG and using osmocon. In other words, UART support only.
The kernel for MTK does not seem to have any signs of gsm layer 1 code.
All known info is here: http://bb.osmocom.org/trac/wiki/MT6235_DSP Once more is known, layer1 could be implemented. Regards, Wolfram
Hi Martin, On Sat, Nov 26, 2011 at 06:52:39PM +0100, Martin Hinner wrote:
I meant l1-related code, some parts - for example http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/mt62x... or http://cgit.osmocom.org/cgit/osmocom-bb/tree/src/target/firmware/board/media... ...
The kernel for MTK does not seem to have any signs of gsm layer 1 code.
please check the list archives http://lists.osmocom.org/pipermail/baseband-devel/2011-March/001554.html and the code in u-boot which the abovementioned link talks about: http://cgit.osmocom.org/cgit/uboot-mt623x/commit/?id=18aa4c659a3e4b1b6262a0f... This is the furthest that has been done on MTK, as far as we know. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Martin,
On the other hand, I have access to very cheap phones using Infineon PMB7880 (C166 + DSP) or MTK (ARM9) chipsets.
Note, that on the market there is much more Mediatek phones based on ARM7 (MT622x) than on ARM9 (MT623x). I mainly focused on MT623x series of Mediatek SoC, which is based on ARM926EJ-S with MMU support. My Linux port for this architecture didn't touch L1 at all. I focused first on getting "application" cpu up and running. This went quite well and then I tried to understand how L1 works. Writing driver for MT6140 helped me understand basics of baseband part of the phone. I managed to configure TX path to transfer data on given frequency and after that I had to have DSP running to send "proper" data. I got stack on DSP part, because I tried first to download firmware from DSP ROM. This didn't work out so far. Better approach would be to disassemble and understand DSP-ARM API and use it as it is, without firmware changing for now. Unfortunately I couldn't find time to work on that due to my professional work. Anyway, all the links are already given in this thread and that's the current status. I described all my findings on OsmocomBB wiki. @Wolfram: I'll probably submit barebox port with update of Mediatek kernel code to 3.2 kernel version. BR, Marcin
Hi Marcin and Martin, On Sun, Nov 27, 2011 at 01:17:37AM +0100, Marcin Mielczarczyk wrote:
On the other hand, I have access to very cheap phones using Infineon PMB7880 (C166 + DSP) or MTK (ARM9) chipsets.
Note, that on the market there is much more Mediatek phones based on ARM7 (MT622x) than on ARM9 (MT623x).
ACK.
My Linux port for this architecture didn't touch L1 at all. I focused first on getting "application" cpu up and running. I managed to configure TX path to transfer data on given frequency and after that I had to have DSP running to send "proper" data.
All of this, once again, quite amazing work you've been pulling off. I really regret that nobody (including myself) has ever since picked up on it :(
I got stack on DSP part, because I tried first to download firmware from DSP ROM. This didn't work out so far. Better approach would be to disassemble and understand DSP-ARM API and use it as it is, without firmware changing for now.
Indeed, I agree, the best approach (like we took on Calypso) is to try to use the DSP ROM code as-is. This reduces the required work to: 1) understand how to bring up (boot/start) the DSP from the ARM 2) understand how to drive the API from the ARM and feed instructions into the DSP as well as read results 3) writing the required scheduler around those instruction/result primitives, possibly porting/re-using some of the calypso L1 scheduler
Unfortunately I couldn't find time to work on that due to my professional work.
We can all understand that, but it's a real pity... Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 11/27/2011 08:13 AM, Harald Welte wrote:
All of this, once again, quite amazing work you've been pulling off. I really regret that nobody (including myself) has ever since picked up on it :(
I don't receive it like that. Thanks to this I had motivation to switch to baseband part which was always black box for me. I learned probably more investigating and implementing than by analyzing code. It's still in my ambition to get MTK L1 working together with Linux. Especially that MT6516 has some parts similar to old family of MT62xx and we could have a way forward.
Unfortunately I couldn't find time to work on that due to my professional work.
We can all understand that, but it's a real pity...
I'd like to get back to this work and as you see we have new people coming so maybe we'll be able to get it rolling again. BR, Marcin
participants (6)
-
Harald Welte -
Marcin Mielczarczyk -
Martin Hinner -
Mielczarczyk Marcin -
Steve Markgraf -
Wolfram Sang