[PATCH] kexec tools mipsel port
miltonm at bga.com
Tue Jun 26 01:31:10 EDT 2007
On Thu Jun 21 03:52:19 EDT 2007, francesco chiechi wrote:
> On Monday 04 June 2007 07:40, Horms wrote:
>> On Sat, Jun 02, 2007 at 12:21:38AM +0200, francesco chiechi wrote:
>>> We developed a patch to port kexec-tools to mips arch and included
>>> support for command line passing through elf boot notes. We did it
>>> for a customer of ours on a specific platform derived from toshiba
>>> tx4938 (so we think it should work at least for tx4938 evaluation
>>> board also). We would like to contribute it in case somebody else
>>> needs it or wants to improve it. This patch works for us but the
>>> assembler part in particular, should be considered as a starting
>>> because my assembly knowledge is not too deep.
>> I'm curious to about all the #ifdef __MIPSEL__ stuff in kexec.c.
>> Is there no chance that couldn't be placed somewhere in
>> somehow? kexec is a bit hapazard in parts, but generally there
>> isn't much #ifdef ARCH foo in there and we try and keep
>> architecture-specific and generic code separated.
> I am aware of this problem but I did not find a more appropriate way
> to solve
> this. This has something to to with the way mips handles virtual
> I will retry to fix this as soon as I have some time
Looking at your patch, you seem to use this _virt stuff to hold the
(1) Why do you need to allocate the buffer virtual in the generic code?
Just allocate the physical space, and do the translation from
physical to virtual in the architecture code.
(2) Most ports enter purgatory with translation off. I'm not familiar
with MIPS, but did you consider doing this? Your final kernel exit
shouldn't be providing more environment than specified by the user
code. Don't assume the new code will be a Linux kernel.
The design of kexec is the kernel exit to userspace in a very basic
state. The system call provides for specifying memory contents to be
placed at specified locations and an address to start execution. In
most ports, the kernel tuns off the mmu, copies the new kernel into
place, and enters the user space supplied code in real mode. This
code, usually called relocate_new_kernel, is position independent (or
is patched by the kernel exit), self-contained, and actually run from
some address allocated in a hole of the user supplied code. It is
expected that userspace (kexec-tools) will provide a trampoline to get
from this basic machine state to and environment to run purgatory, then
setup what the loaded code (new kernel) expects, including loading
values or pointers in registers and performing any needed fixups to
 64 bit powerpc is split somewhat differently because only a small
fraction of memory is reachable in real mode. We copy before killing
the mmu. This requires special considerations to keep the mmu alive
during the copy. I've written a few emails on this topic; I need to
gather them and write a file for Documentation/).
More information about the kexec