about ppc32/kexec

[Albert Herranz]

Hi,

> Thank you for the details. Can you explain why with MMU on
> it needs to
> assume in-place memory mappings? Do we always have __pa or
> __va
> available to translate between? We don't need to assume any
> mapping
> since on ppc32 you can always get to virtual address by
> adding
> PAGE_OFFSET to physical address.

Is CONFIG_HIGHMEM covered by that?

> I try to implement kexec for freescal 85xx and IBM44x
> platform so the
> current code for ppc32 definitely need to be either move to
> gamecube
> specific or I create stub for each of 85xx and 44x, which I
> try to
> avoid.

The current code is not gamecube specific, it is ppc32 generic and works for platforms that can turn off their MMU, which is the general case. 44x seems to have a lot of particularities. Guess that's why it has its own *.S's.

IMHO, at least you should try to keep the kexec interface as defined (all kexec structures use physical addresses).

If you can't turn off the MMU on those platforms, you need either to use a 1:1 mapping or deal with the special case in a special way.
You can modify the existing relocate_new_kernel and special case the 4xx or you can create a new relocate_new_kernel_4xx and use that if 4xx.

One way to follow/keep the kexec interface on 4xx for relocate_new_kernel might be:
- relocate the kernel translating physical addresses using a known mapping that can deal with all the memory that kexec is told to use to store the image (i.e. the memory that kexec_load uses to put the different pages that make up the image).
- then get rid of all the memory mappings, make sure to enable a 1:1 mapping that covers all the range of memory supported and jump to the entry point of the loaded image.

Another one could be:
- get rid of all the memory mappings, enable a 1:1 mapping and do the relocation using physical addresses (as they can be used directly then).
- jump to the entry point of the loaded image.

What do you think?

Cheers,
Albert