but there has to be a version of kexec for android-modified kernels or atleast ARM-linux kernels.
On Jan 5, 7:58 am, "Arun K. Singh" <arun...@gmail.com> wrote: > <http://www.crazydaks.com/> > > On Wed, Jan 5, 2011 at 10:01 AM, Chris Stratton <cs07...@gmail.com> wrote: > > On Jan 4, 9:06 pm, Srikant <w.sreeka...@gmail.com> wrote: > > > I agree with you, if the requirement is porting to a new h/w platform. > > > > But the requirement here is to just porting to a new Linux Kernel > > > version, hence it may not be required to do assembly level debugging. > > > I'm not sure that it isn't quite comparable to porting to a new > > platform. > > > Agree to it. If you are kexecing a plain vanilla (different)kernel, you > > still need to re-port arch specific code right from header.S to > main.c[depending on specific architecture]. may be diff these files between > running kernel and new vanilla version and paste to vanilla. > > You've either got to figure out what the thing that usually runs > > > before the kernel does in the way of setup and duplicate that in the > > kexec code so that a stock kernel will start up correctly, or you've > > got to modify the kernel startup code to work forward from the > > configuration in effect at the time kexec under the old kernel hands > > over to it. > > > You know the kernel should work once the low level startup/handoff is > > properly accomplished - the work to be done is figuring out that low > > level part. Which I think is probably a lot like porting. > > > yes but once the new kernel is kexeced/loaded and before "real" consoles > > could be registered it may good idea to register "boot" consoles via early > printks ... -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
