booting another linux kernel from a running android system

[Earlence]

Is it possible to run another kernel (shutting down the previous
system) via an sd card from an already running android system?

I've looked at the linux for ARM boot process and several more general
techniques like kexec and 2 kernel monte.
any pointers?

Cheers,
Earlence

[Chris Stratton]

I should be possible to set up, but I didn't get it to work in the
brief time I spent trying. And it's likely going to require running a
patched kernel to start.

If you want to work on it, I'd highly recommend first getting a
working serial output for kernel messages, both hardware wise on your
device and having a simple bare bones driver for it.

[Earlence]

thanks. if you can share more of your work done, it will be helpful
(and save time also)

[Earlence]

a starting point?

[Chris Stratton]

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.

[Srikant]

> 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.

Instead of this, you can enable Kernel Low Level Debugging options in
Kernel Configuration for the new Kernel, so that you can get initial
kernel messages until UART driver is initialized.

[Chris Stratton]

> Instead of this, you can enable Kernel Low Level Debugging options in
> Kernel Configuration for the new Kernel, so that you can get initial
> kernel messages until UART driver is initialized.

If you survive far enough into the boot that any generic parts of the
kernel are running. I was thinking more of generating output while
still in the device specific, likely assembly language initialization.

[Srikant]

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.

[Chris Stratton]

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.

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.

[Arun K. Singh]

On Wed, Jan 5, 2011 at 10:01 AM, Chris Stratton <cs0...@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 ...

[Earlence]

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/>