On Jan 3, 5:53 am, Earlence <earlencefe...@gmail.com> wrote: > a starting point?
As I said, I would first work on getting hardware and low level drivers so you have a serial (not USB) messages output from very early in the kernel boot process. Then install a kernel with kexec enabled. Then try booting another kernel from it and watching the serial output to see how far it gets before it hangs. If you don't see anything, hardcode a character or two of output from the very start of the kernel startup routine, that sets all necessary registers explicitly. You could for example set it up to count '0' '1' '2' '3' etc with each digit added after another block of the startup code, up to the point where you have printk() functionality working. One of the real complications is likely to be that on a typical dual- core android phone (original style with radio & application cores, not dual application cores as now being advertised), it's actually the radio processor which handles rebooting. So to use kexec, you are going to have to get the application processor to simulate a startup condition without actually having been rebooted (because if you reboot the radio processor, it will load the flashed kernel). Another option could be to build yourself a little lilo- or grub- style menu into the early stages of the kernel, so that you actually do reboot the entire phone, but get the option to pick an alternate kernel before the default kernel has really started up and changed the run environment from what an alternate kernel would expect to find on startup. -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
