All the Conexant code that I have looked at did use the same stuff. The boot based checksum, number of bytes that the checksum is over both were in the same spots, but the location in RAM that was used for execution differed and in one case the code was not moved to RAM but executed in flash. The use of odd addresses for the Task handler installation seems to be common as well, but the exent to which the use of odd addresses was usefull in IDA disassembly varied. And two of the three cases had the code compressed, so you have to extract the info first.

Coolsat 5000 had lh5 compression, executed code in flash (at 0x20020000) and odd addrs did very good job in IDA. Pansat 250 had inflate/deflate compression and I had to fake a gx type header to get 7Zip to extract the code, code executed at 0x500000 in RAM and the odd addresses gave me about 75% disassembly.

For other Conexant based boxes, you will have to see if the code is compressed or not (there is a 'stupid un zipper' called Stunz that will try 5 different compression schemes in extracting code and it is my first method of trying to find compression type--though the results are not pretty--if you have idea of the form of the compression header it can be easier to look for compression type that way: "PK"=standard zip, 'lh5'=well, lh5, '0x1f 0x85' inflate/deflate). Once you have clear code, look for "CNXT" and Conexant Copyright strings--just after CNXT string will be the location for execution. If you get that far then mod the source of the odd_addr program and get yourself a copy of lcc_win32 to compile it and see what you get.