The TriMedia VLIW core found in 2Wire devices uses a compressed instruction stream.
Each operation in the instruction – five ops per instruction for the TM32 core and eight ops for the TM52 core – is individually compressed in memory and in the instruction cache. Instructions are decompressed on-the-fly at run-time.
The instruction compression scheme is conspicuous by its absence from all official datasheets, manuals and books for the CPU.
The presence of a hardware-based instruction decompression unit is briefly acknowledged in the literature, but it is not described.
The following excerpt is the sum total of documentation on the decompression unit in the TM3260 Architecture Manual: [3]

In one manual the authors insist that the programmer need not understand the TriMedia object format since the toolchain shields him from that.
That’s no problem if you plan only to use the proprietary (US$3000) development tools for the TriMedia.
But what if you need to achieve something that the official tools aren’t equipped to do? Such as reverse-engineer a bootloader image?
Bootloader images are typically ‘raw’ binaries and have no object container, like ELF, a.out or COFF.
In the GNU-Linux world, the ever faithful objdump utility from the binutils package can disassemble raw object code.[1]
However, tmdump, the proprietary TriMedia counterpart to objdump, will only disassemble binaries that are contained in a TM object.
No doubt, the TM object format can be reverse engineered. This would allow raw object code to be added to a text segment of a tmobj and then disassembled.
Better, perhaps, is to understand the instruction compression scheme used by the TriMedia, so that a basic disassembler can be engineered around that.
Aside from the instruction compression scheme, the rest of the documentation for the TM32 processor seems adequate for the task.
All of the opcodes and operands are listed in the publicly available TriMedia Architecture Manuals [2][3][4]
And a description of the TriMedia VLIW compression scheme can be found in obscure documents filed by Philips Semiconductors with the US Patent Office. [5][6][7][8][9]
The pivotal part of the scheme is described in a table, duplicated below.
The full scheme is slightly more complicated (or should that be simplified?) through the use of operation aliases.
So, to date, that defines the hack progress.
[2] https://docs.google.com/open?id=0B6wW18mYskvBNjcyMDRmZWItNmFmZS00MzBkLTkwNWQtZDFkMWJlODk4NTFj
[3] https://docs.google.com/open?id=0B6wW18mYskvBMzQ2ODk5MTQtMDRlMC00OGI0LWFmZjYtMTI5ZGY3OGVkYWU1
[4] www.compel.ru/images/catalog/383/tm_5250_user_manual.pdf
[5] http://www.google.co.uk/patents?id=4lMkAAAAEBAJ
[6] http://www.google.co.uk/patents?id=wFYYAAAAEBAJ
[7] http://www.google.co.uk/patents?id=rcsXAAAAEBAJ

