The Mondrian NBH posted in this thread is a format that HTC uses, that you can consider a "container" like a cup or a box. We know this format fully and can dump and create it at will (NBHImageTool)
The qualcomm snapdragon can be thought of a miniature dual-core computer. It is different from a normal computer that has dual cores in an important way: Each core is assigned it's own block of memory, and runs its own operating system. There is a shared block of memory allowing the 2 operating systems to communicate with each other.
Inside that .nbh container, are some more containers. One is "radio.nb" - inside here is the various software that drives the "second processor". Another is "spl.nb" - this contains the tri-color bootloader that most of you are familiar with as HardSPL. This bootloader has changed considerably for WP7 and it's layout will need to be determined. Another is "unknown-0x0804.nb", as you might guess we don't know what that is yet
Finally, there's "os.nb" - the last container. This one has the OS we want to work with (WP7), and really it's not os.nb as that is the format used on WM6, so far all the WP7 ROMs ive seen use the "flash.store.bin" container format. My NBHImageTool currently names the output file incorrectly as os.nb. I will update a future version to check the actual content of the file and name it properly (flash.store.bin)
In order for us to port the OS from one device to another, one basic thing we need to be able to do is "dump" the "flash.store.bin" container format to its components (I did this manually with a hex editor, and posted on post 2 of this thread), and re-build the flash.store.bin from those components (after we've edited them to do the actual "porting")
We don't yet know the flash.store.bin container format, which is the current hurdle i'm working on. Once we are able to easily dump/rebuild that, there are a number of other challenges to meet, such as how we relocate modules to function on another device. Modules are built with a pre-determined memory layout, and each device has a different memory layout. On WM6.x ROMs we have the tool "g'reloc" or "wmreloc" or "platformrebuilder" to handle this for us. With WP7 ROMs the memory layout is entirely different, so a new tool needs to be developed.
We currently don't yet know how the memory layout looks, i've just been going by CE6 documentation on MSDN. If we're lucky not much has changed in that regard, and we'll be able to create a relocation tool based on that documentation.
Anything that has changed since then will need to be reverse engineered. If that is necessary it probably won't be likely until we can get hands on a device running WP7, inject some native code, and figure out the memory layout and other such goodies.
So, assuming we have those things hammered out (we don't yet), we need to make our current device bootloaders able to load the WP7 OS. This would be accomplished using some ARM assembly trickery. This is where JTAG comes in because there's a high probability of bricking and we will be able to obtain debug output from the process to determine where any failures are occuring (and there will be failures!) - another hurdle with this is that it's looking like there is only one JTAG unit capable of supporting the snapdragon at this moment, and it costs upwards of 4x the original donation drive guesstimate, which is far too expensive for this project. I'm currently researching alternatives. It's looking like I will end up having to go with one of the less expensive "home brew" JTAG models and writing my own Snapdragon support into OpenOCD (the open source debugger platform that the "home brew" JTAGgers use) - that is far from a trivial task and i'm not looking forward to it at all :P
Once that's hammered out, we'll be at a place where the OS itself is loading up. However it is quite likely at that point, some of the drivers will fail to work (hopefully not basic ones such as the kernel, display, etc.) - here we'll have to perform some more trickery to get the drivers functioning properly. One potential problem is that since we will be using our original device's radio.nb, more than likely the protocol the drivers use to communicate with it will be different. This will need to be changed.
Now, all of the above stuff needs to be packaged into a deployment system that's user friendly, and relatively fail-safe (we don't want bricks!)
At that point, it's "done" - not complicated at all, right?