Okay, so keep in mind that I'm still learning too, but here's the situation as far as I understand it (which might be less than I think I do). My apologies if I oversimplify this, but it might be useful to others too
There are actually two processors in our phone - there's an arm9 processor that controls the actual cell phone bits. This processor needs some software to run. This software is what we refer to as the radio.img. It's a big binary proprietary blob. This part of the phone also controls things like whether the phone is SIM-locked to a provider (Telus) or Sim-unlocked and can use other sim cards. It is, gererally speaking, locked down and inaccessible to us, the user. We can get some information about it by sending funny commands into our phone - for example, if you punch in *#06# in the dialer, the radio spits out your IMEI number. Other codes change other settings. Most of these are standard for any phone that uses the same chip and baseband, regardless of whether their running symbian, android, wp7, whatever.
Then we have a second processor on our phone, an arm11 processor. This is the phones 'main cpu', which runs android. It's really a full fledged computer, with all sorts of things integrated, like 2d and 3d GPU's and such. This is the part we get to play with. Pretty much all hardware on the phone is connected to this CPU, including the wifi, graphics, touchscreen, etc. This means we get to control these devices from android.
Additionally, inside the kernel, there's a bit of code referred to as msm_proc_comm - this is the interprocessor communication code that allows our main CPU to send and receive commands from the radio's CPU. This is how the phone gets data to and from the mobile network, etc.
The unfortunate thing is that anything in the radio is off limits to us. Sad, really, but probably a good thing from a regulatory position - imagine if we could arbitrarily change our cell frequencies, transmit power, or even spoof our phone as being someone elses. Anyway, this stuff is all in the radio bits.
Our kernel contains drivers for all the other hardware, and drivers to communicate with the radio.
For a few things, this is easy, like the keyboard. There's some wires that connect the keyboard to the cpu. If there's voltage on those wires, a key is being pressed. Figure out which wires, and in what combo, and the kernel knows which key it is.
However, most drivers contain something called firmware. Firmware is a sort of software that is loaded into the hardware itself to program the behaviour of the chip. Many of our phone's devices require firmware to operate. So far, I can see that the 3D graphics, bluetooth and wifi require firmware, although the touchscreen and a few others might too.
The 3D graphics firmware is located in /system somewhere... they have file names like yamato... Bluetooth has firmware somewhere, but I haven't tracked it down yet... the wifi firmware is called BCM4329B1_002.002.023.0313.0341.hcd or similar, depending on the version of the phone... I think the program called tsdown loads firmware to the touchscreen too.
Anyway, the firmware is all binary blobs. The kernel loads the firmware into the device when it initialises that device's driver. The drivers themselves are open source, but the firmware is not and needs to come from the manufacturer.
So, the short answer to your question: some of this is in the radio.img (inaccessible), some is in the kernel (which we can make), and some is in system.img as binary firmware. We should be using the kernel and firmware that matches our phone, or things will simply not work.
This means, we need to use the radio, the kernel, and the firmware that matches our phone. We'll also need a few other odds and ends, such as the startup scripts that ensure all the right drivers and firmware get loaded when we boot. If we can isolate the firmware and startup scripts in system.img and boot.img, we're laughing.
Aside from that, we can probably get away with anything else installed, assuming it's compiled for armv6 and not armv7. See, most of the apk's that one installs on android are written in java. They are machine agnostic. The underlying bits that power the phone, however, are not. So, by simply porting in non-java files from other phones, there's no guarantee that they'll run on ours. Phones with the same CPU are probably safe though. For example, the CM7 port to the ZTE Blade might be a good place to start from, since it has the same CPU.
Wow, wordy today. Hope that's useful.
I'll work from the angle of getting a build specifically created for our phone. If you want to try to do it by stitching together the differences between ours and another phone's rom, please indulge yourself. One way might be more successful than others at this point.
...
(Just activating CRT off in framework does not work, they pulled the CRT off animation from the code)