Linux kernel is a piece of code, and every mobile phone is a little clone of somewhat that resembles to an old IBM PC (or Mac or Solaris etc.) which is capable of executing pieces of code (that’s why your mobile phone works..)
Running Linux successfully on the phone depends on how openly the phone’s manufacturer has architectured it.
In the worst case, on your chosen mobile you can execute at a low-level in kernel-mode a piece of code to sum two numbers on the processor once you power on your gadget; but you’ll never be able to observe it, because neither keypad nor screen would work nor anything else would work!
Putting it in a very simple words: If all specifications are closed, and you still want Linux on your precious handy, you would have to collect all the drivers from every chip inside your phone (by unscrewing and googling what’s written on a chip on the board) and/or reverse engineer and write drivers on your own, then put everything together and have a Linux kernel modified on your name, then you can be enough called an ultra-craze.
In the best case you can have a whole chosen distribution of Linux running on your handy, supporting all devices (screen, keypad, GSM, wifi, bluetooth, IR, USB etc)
We rarely end up on the best case, but we are fighting not to stuck in the worst one, by trying to find a Linux-friendly mobile phone.
Wiki your mobile phone(s) hardware specs. You will most of the time find out that the CPU is an ARM family processor, which is “good” because you can download an ARM compiled Linux image to add those two numbers for you..
If the internal chips of you mobile phone are wired together based on an open composition of hardware parts, such as TI OMAP (on Nokia N70, or a successful Linux on Siemens SX1), your future may be brighter.
Linux (kernel) is started when its kernel image is loaded into the memory and is being executed by the CPU.
To prepare (clear, reset) the system for booting an operating system kernel, then finally to put its image into RAM you need another software (a boot loader) to do this, and it needs to have sufficient privileges to run.
You can (somehow) make this software run either from the cold boot (startup) finding a way to flash (overwrite) the internal ROM, which normally contains a boot loader for your (hated:)) Symbian, Sony Ericsson OS, Windows Mobile or other OS.
Here is the point when you enter the system programming world: you have to know the ways to flash ROM — manufacturers try to protect it by all means for people/businesses not to tamper with their phones, — basically it’s again all about finding security holes..
If flashing ROM cannot be achieved, you need to see what you can do from within the running phone’s native operating system (I let alone the JTAG and soldering iron solutions for ultra-geeks and do not describe them here)
If it is possible to develop software for your mobile phone in something lower-level than Java (Symbians SDK C++, C on Windows Mobile) and the executing code would have or would give your program (another security hole search..) the kernel-mode privileges, you can consider yourself lucky and start programming a boot loader, which would clean/resetCPU registers, display, memory and other ports away from the running OS, and then to load the kernel’s image bootloader (U-Boot, or other loaders) from a storage (SD card) into memory, and would make the processor to execute it, you can consider calling yourself a lucky Linux spawn-er.
This is not the end: U-Boot has to be compiled for your phone’s architecture, and internal hardware wiring, so it could continue resetting the system and loading the actual Linux kernel image into memory. U-Boot for OMAP exists (luckily), but still has undergone numerous patchworks by low-level system programmers, who were devoted to have Linux on the aforementioned Siemens SX1.
In any case if you are not an expert in this field, you need to build a network of support from the people in that area of low-level system programming, to help you out when you get stuck.
Good luck Linux freaks!