27 Nov
2011
27 Nov
'11
5:44 a.m.
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
28 Nov
28 Nov
9:15 a.m.
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.
BR,
Marcin
2:33 p.m.
On Mon, Nov 28, 2011 at 9:15 AM, Mielczarczyk Marcin
<marcin.mielczarczyk(a)tieto.com> wrote:
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.
There are some files missing so you cannot even link the project into
binary... but I agree that some missing files are due to lib-only
distribution of the platform files.
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.
I know, I have already disassembled all of this and it all makes sense.
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
Can you share you DSP work with me? You can mail it directly to me so
as we're not posting useless data on the mailing list (at least for
most people).
I have extracted the patching code from binary (it's 8192 bytes long),
there are 2 of them. I do not have any disassembler for AD's DSPs, so
I had to do it manually, but the code did not match any opcodes (the
resulting code did not make any sense).
Martin
4554
days inactive
4555
days old
baseband-devel@lists.osmocom.org
2 comments
2 participants
participants (2)
-
Martin Hinner -
Mielczarczyk Marcin