RE: about ppc32/kexec

RE: 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



      


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: about ppc32/kexec

[Eric W. Biederman]

Albert Herranz <albert_herranz@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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: about ppc32/kexec

[Albert Herranz]

Hi,

> I don't understand why you choose to turn the MMU off on
> ppc.. Is there
> any practical reason? On Freescale 85xx which is close to
> PPC44x, I did
> not turn off MMU(I cannot) and I just rely on the current
> virtual to
> physical mapping to jump to the start address to execute
> the second
> kernel.

kexec is designed to boot whatever self contained executable image you want (linux or any other binary). In fact, the ppc port was developed on a GameCube, and was designed to boot Linux and non-Linux binaries from Linux.

It currently avoids making assumptions about in-place memory mappings and works in real addressing mode.
The MMU is turned off to switch to real mode addressing. The relocation code works in real addressing mode to copy the image to its final place and then jumps to the entry point of the loaded image, in real addressing mode.
On kexec-tools, depending on the type of executable image loaded, a small stub is used as the entry point which setups whatever environment (address mappings if needed, etc.) the loaded binary expects, and then jumps to the actual entry point of the binary.
In this way, the setup of the different possible environments for the different types of binary images than can be loaded is moved from kernelspace to userspace. The interface between the kernel and kexec-tools is well defined and constant.

On platforms that cannot turn the MMU off you may need to choose another approach. And you may need to fix kexec-tools too to account for that.

Cheers,
Albert



      


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: about ppc32/kexec

[Ming Lei]

Albert,

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.

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.

Ming


> I don't understand why you choose to turn the MMU off on
> ppc.. Is there
> any practical reason? On Freescale 85xx which is close to
> PPC44x, I did
> not turn off MMU(I cannot) and I just rely on the current
> virtual to
> physical mapping to jump to the start address to execute
> the second
> kernel.

kexec is designed to boot whatever self contained executable image you
want (linux or any other binary). In fact, the ppc port was developed on
a GameCube, and was designed to boot Linux and non-Linux binaries from
Linux.

It currently avoids making assumptions about in-place memory mappings
and works in real addressing mode.
The MMU is turned off to switch to real mode addressing. The relocation
code works in real addressing mode to copy the image to its final place
and then jumps to the entry point of the loaded image, in real
addressing mode.
On kexec-tools, depending on the type of executable image loaded, a
small stub is used as the entry point which setups whatever environment
(address mappings if needed, etc.) the loaded binary expects, and then
jumps to the actual entry point of the binary.
In this way, the setup of the different possible environments for the
different types of binary images than can be loaded is moved from
kernelspace to userspace. The interface between the kernel and
kexec-tools is well defined and constant.

On platforms that cannot turn the MMU off you may need to choose another
approach. And you may need to fix kexec-tools too to account for that.

Cheers,
Albert



      


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: about ppc32/kexec

[Ming Lei]

Albert,

>> 
>> 1)       In relocate_new_kernel, you put the comment saying switch
the >>MMU off. Can you tell me how these code can achieve it. I don't
see it >>happens on FSL85xx(actually 85xx or 44x doesn't allow MMU to
turn off).
>> 
>> +       .globl relocate_new_kernel
>> +relocate_new_kernel:
>> +       /* r3 = page_list   */
>> +       /* r4 = reboot_code_buffer */
>> +       /* r5 = start_address      */
>> +
>> +       li      r0, 0
>> +
>> +       /*
>> +        * Set Machine Status Register to a known status,
>> +        * switch the MMU off and jump to 1: in a single step.
>> +        */
>> +
>> +       mr      r8, r0
>> +       ori     r8, r8, MSR_RI|MSR_ME
>> +       mtspr   SRR1, r8
>> +       addi    r8, r4, 1f - relocate_new_kernel
>> +       mtspr   SRR0, r8
>> +       sync
>> +       rfi

>This code sets the MSR to a value where MSR_IR (Instruction Relocate)
and >MSR_DI (Data Relocate) are cleared, and thus the MMU is turned
effectively >off.
>Turning the MMU off is possible at least on 6xx and 7xx.

I don't understand why you choose to turn the MMU off on ppc. Is there
any practical reason? On Freescale 85xx which is close to PPC44x, I did
not turn off MMU(I cannot) and I just rely on the current virtual to
physical mapping to jump to the start address to execute the second
kernel.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec