Hi,
I've been slowly working on the DSP code for some time now and I tought I'd post a status here in case other people are interested.
The ultimate point of this is to add support for things the DSP isn't supposed to do. Like receiving the raw demodulated data without the deciphering / fire code / whatever. Or dealing with raw speech data ... sending other type of burts like SCH / FCCH, or receiving other type of bursts like RACH, ...
The DSP ROM dumper has been present for a while but there was no way to really use the output efficiently. For that, I've written a parser that takes the console log output and converts it into a COFF file that you can load in your favorite disassembler.
I've been working with IDA 5.6 mostly and I made several enhancement to it to support the calypso better (the tms320c54 module is part of the SDK and can be modded and recompiled) : - Add support for memory mappings so that the same memory zone can 'appear' at several place in the address space (to handle data & code overlay) - Fix the section handling when loading a file: . to set XPC properly, . to not override section name . to support more than 2 sections - Fix a bug in cross reference detection when dealing with section having selectors != 0 - Add stub support for the type system. This allows loading of a .h header file with the NDB structure definition - Add definition for the IO ports so that they are symbolically displayed
Here's a sample results of what it looks like now (without much manual fixups, just loading the files and declaring a couple addresses as being structures) : http://www.246tnt.com/files/calypso_dsp_ida_sample.png It becomes clear what function does what :)
I'll try to push a maximum in my dsp branch tomorrow. I can't put the IDA processor module modification because even just the patch contains some hex-rays code, so I guess I'll have to ask them permission on a case by case basis to distribute it. (just ask me privately and we'll work it out)
Cheers,
Sylvain
Hi Sylvain,
thanks for your status update.
I would be interested in playing with your IDA work, but I'm currently really on holidays and try to stay away from getting involved in even more aspects of the project. So I'll check your currenv version in mid-April...
With regard to patches: I thought there were some non-context variants of diff. In that case, even a diff does not include original code before you patched it.
Those diffs are very flaky to apply and don't work if you have any local modifications, of course. But assuming everyone got the same source to the plugin in the IDA SDK, it should work.
Also, as dieter has indicated, he knows Hexrays well and I think it should be no problem to get your modifications merged in the next IDA release and/or published somewhere on their website.
Regards, Harald
With regard to patches: I thought there were some non-context variants of diff. In that case, even a diff does not include original code before you patched it.
Yes there is. But I actually got new versions of the tms320c54 files from Hex Rays themselves for some bug I reported.
I then modified those to add some calypso specific code.
Also, as dieter has indicated, he knows Hexrays well and I think it should be no problem to get your modifications merged in the next IDA release and/or published somewhere on their website.
Yup most of my modifications should be in the next version, I've sent them to Hex Rays.
Cheers,
Sylvain
Hi everyone,
I've been slowly working on the DSP code for some time now and I tought I'd post a status here in case other people are interested.
So, here we are, 8 days laters, I tought a small update would.
Now that my IDA works nicely with the code. I started really digging into what it does.
* First, the code makes heavy use of jump tables and indirect call. Most of the init is to copy function pointers (or a few times, function themselves) from the ROM to the RAM and then use them from RAM. This kinda screws with the autoanalysis of IDA and I'll have to write a script to handle that gracefully. That also means that you can override those jump tables with whatever you want. After the init is done, the DSP will jump to the address set in d_grps_install_address. Currently we point this one to 0x7002 which is just a 'ret' instruction but we could put in the API ram a custom function that hooks whatever we need.
* Second, I found the main demodulation routines :
- prom0:7c27 -> Normal burst decoding : This starts with 190 IQ samples (16bits I, 16bits Q) at the start and finishes with 114 bits + 2 stealing bits at the end of the array. At the output they are not hard bits but still 'semi-soft bits', that is it's a 4 bits signed value between -8 -> 7, even after deciphering. I think they keep them soft so that when applying the error correction they can take advantage of that information somehow. (that's unverified for now tough)
- prom0:7c2c -> SCH burst decoding : This starts with 190 IQ samples as well and finishes with 78 softbits. I haven't dug much into this one yet, but the final memcpy of 78 values makes me think this is SCH :)
It's also interesting to note that the raw IQ values should still be in the API zone after demodulation :)
* Third, when looking at the code, it sometimes look like a mess ... there is no calling convention that I can see, every function seem to have it's own way of making. There is also very little stack usage for temporary variables, they seem to use global variables for that and the same variable can be re-used somewhere else with a completely different meaning ...
I'll continue digging in the demodulation stuff to see how they do the demod exactly. It's my experience that they're much better at it than airprobe is and I want to find out what tricks they have up their sleeves :)
I'll probably also have a look at the TX side, see if I can hook something to TX FCCH/SCH frames somehow ...
Cheers,
Sylvain
On Thu, Mar 18, 2010 at 09:48:16PM +0100, Sylvain Munaut wrote:
Now that my IDA works nicely with the code. I started really digging into what it does.
thanks for your update.
It's also interesting to note that the raw IQ values should still be in the API zone after demodulation :)
This is interesting, but almost expected. As far as I understand it, the DMA from the BSP can only transfer into the API RAM. So unless that portion of API ram is reused, the values inevitably still have to be there.
- Third, when looking at the code, it sometimes look like a mess ...
there is no calling convention that I can see, every function seem to have it's own way of making.
It is normal for such code to be hand-crafted DSP assembly, so I'm not surprised you won't see fixed calling conventions like a compiler would generate (or a mixed C / assembly project would require).
Regards, Harald
baseband-devel@lists.osmocom.org
-
246tnt＠gmail.com -
Harald Welte -
Sylvain Munaut