about ppc32/kexec

[Eric W. Biederman]

Albert Herranz <albert_herranz at yahoo.es> writes:

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

I think the loaded image should be presented with a 1:1 virtual to
physical memory mapping and get the chance to figure out what to do
from there.  It is a nice least common denominator environment that
every architecture and every variation can support, and I expect
it will facilitate code sharing with the existing gamecube port.

I don't have a clue what kind of MMU the 85xx and the 44x have.  ppc has
done all sorts of weird things in the past.  But my experience on other
architectures like alpha, ia64 and x86_64 has been that setting up the
paging infrastructure to do a 1:1 virtual to physical mapping hasn't
been too hard even when you can't turn off the MMU.  Turning off the
MMU is just easier.

Eric