* Kumar Gala | 2010-05-07 01:50:29 [-0500]:
>Can you explain this a bit more. Mostly would like to have a brief
>description of the sequence of events as part of the commit message.
>
>Something like:
>
>* Running kernel calls machine_kexec()
>* machine_kexec_32()
>* jump to relocate code
>* relocate clears out TLBs and sets up 2g mapping
>...
>
>what I have above might not be quite right.
That is correct:
- kexec -l loads the kernel, dtb, ... in userland. It sets up the kimage
struct including buffers with the new kernel and a copy list which
looks like src, dst, bytes.
KEXEC_*_MEMORY_LIMIT is limiting the memory which it might allocate.
- kexec -e start the kexec, that is
* syscall reboot - kernel/sys.c
* kernel_kexec() kernel/kexec.c
* machine_kexec() arch/powerpc/kernel/machine_kexec.c
* default_machine_kexec() arch/powerpc/kernel/machine_kexec_32.c
- copy relocate_new_kernel() into a buffer which was allocated during
kexec -l. That buffer is somewhere between 0..2GiB and will not be
overwritten.
- jump there.
Here we clear the tlbs and setup a 1:1 mapping. Then we copy the
data from somewhere in 0..2GiB to its final position according to the
list. Data means new kernel, device tree and purgatory code.
- After that, the code ends in
mtlr r5
blrl
r5 has the address of purgatory_start(), purgatory/arch/ppc/v2wrap.S
in kexec userland [0].
- here we setup stack, jump to purgatory(). We have no console and still
the 2GiB 1:1 mapping
- the code performs a sha256 check to make sure the kernel is correct.
- then we get back from purgatory(), load r3 - r9 and the blr at the
bottom shoots us finally to new kernel.
- now we boot the kernel.
>- k
[0] git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git
Sebastian
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
