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 https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.comHi 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