MTK and Infineon-based phones

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at

Mielczarczyk Marcin marcin.mielczarczyk at
Mon Nov 28 08:15:25 UTC 2011

Hi Martin,

On 11/27/2011 05:44 AM, Martin Hinner wrote:
> 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?)

Files are deleted by purpose. This code is probably uploaded by customer 
of Mediatek platform (some phone producer), and they don't get source 
code for all of the parts. Most probably even in Mediatek company L1 and 
DSP code is shared as libraries and only people working on development 
of these parts have access to source code.

> I think none of these are needed for our stuff.

I agree.

> dsp_ram.lib: ddload.c
> dsp_ram.lib: dsp_ptch_6223.c (we can get this from binary)
> dsp_ram.lib: idma.c

These files are responsible for uploading of DSP patches and are crucial 
to understand upload process. I tried with Krzysztof Antonowicz to 
upload some DSP code and try execute it using routines from these files 
but no successes at all. I described some of them on the wiki as you 
probably saw.

> l1.lib: m*.c (it's a lot of files !!!!!!!!!!!!)

These m*.c are important and I remember that I tried to find source code 
for them. I don't remember right now what was implemented there, but 
I'll take a look on it and refresh my memory.

> 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 was disassembling code on running target using JTAG which is much 
easier than static analysis. As I written before, I focused so much on 
getting execution of my code on DSP, that when it didn't work I gave up. 
But it's not the way to go. As you have written, libraries are pretty 
readable and we're able to understand how to use DSP with existing code. 
I'm willing to get back to this work, so I can help you with that.


More information about the baseband-devel mailing list