[kexec-lite PATCH V2] trampoline: Reset primary cpu endian to big-endian

[kexec-lite PATCH V2] trampoline: Reset primary cpu endian to big-endian

[Samuel Mendoza-Jonas]

Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
meaning if we kexec from a little-endian kernel the target kernel will
fail to boot.
Returning to big-endian before we enter the target kernel ensures that
the target kernel can boot whether or not it includes FIXUP_ENDIAN.

Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
---
V2: As suggested by Anton take advantage of the rfid call and switch off
MSR_LE and branch to the target kernel in the same step.

 kexec_trampoline.S | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/kexec_trampoline.S b/kexec_trampoline.S
index a3eb314..3751112 100644
--- a/kexec_trampoline.S
+++ b/kexec_trampoline.S
@@ -88,8 +88,15 @@ start:
 
 	li	r5,0
 
-	mtctr	r4
-	bctr
+	mtsrr0	r4
+
+	mfmsr	r5
+	clrrdi	r5,r5,1 	/* Clear MSR_LE */
+	mtsrr1	r5
+
+	li	r5,0
+
+	rfid
 
 . = KERNEL_ADDR_OFFSET
 kernel_addr:
-- 
2.4.5

Re: [kexec-lite PATCH V2] trampoline: Reset primary cpu endian to big-endian

[Scott Wood]

On Wed, 2015-07-08 at 13:29 +1000, Samuel Mendoza-Jonas wrote:
> Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
> meaning if we kexec from a little-endian kernel the target kernel will
> fail to boot.
> Returning to big-endian before we enter the target kernel ensures that
> the target kernel can boot whether or not it includes FIXUP_ENDIAN.
> 
> Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
> ---
> V2: As suggested by Anton take advantage of the rfid call and switch off
> MSR_LE and branch to the target kernel in the same step.
> 
>  kexec_trampoline.S | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/kexec_trampoline.S b/kexec_trampoline.S
> index a3eb314..3751112 100644
> --- a/kexec_trampoline.S
> +++ b/kexec_trampoline.S
> @@ -88,8 +88,15 @@ start:
>  
>       li      r5,0
>  
> -     mtctr   r4
> -     bctr
> +     mtsrr0  r4
> +
> +     mfmsr   r5
> +     clrrdi  r5,r5,1         /* Clear MSR_LE */
> +     mtsrr1  r5
> +
> +     li      r5,0
> +
> +     rfid

Is kexec-lite meant to be specific to book3s-64?  The README just says "A 
simple kexec for flattened device tree platforms" and I see a __powerpc64__ 
ifdef in kexec_trampoline.S (but not in the above patch)...

-Scott

Re: [kexec-lite PATCH V2] trampoline: Reset primary cpu endian to big-endian

[Samuel Mendoza-Jonas]

On 08/07/15 13:37, Scott Wood wrote:
> On Wed, 2015-07-08 at 13:29 +1000, Samuel Mendoza-Jonas wrote:
>> Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
>> meaning if we kexec from a little-endian kernel the target kernel will
>> fail to boot.
>> Returning to big-endian before we enter the target kernel ensures that
>> the target kernel can boot whether or not it includes FIXUP_ENDIAN.
>>
>> Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
>> ---
>> V2: As suggested by Anton take advantage of the rfid call and switch off
>> MSR_LE and branch to the target kernel in the same step.
>>
>>  kexec_trampoline.S | 11 +++++++++--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/kexec_trampoline.S b/kexec_trampoline.S
>> index a3eb314..3751112 100644
>> --- a/kexec_trampoline.S
>> +++ b/kexec_trampoline.S
>> @@ -88,8 +88,15 @@ start:
>>  
>>       li      r5,0
>>  
>> -     mtctr   r4
>> -     bctr
>> +     mtsrr0  r4
>> +
>> +     mfmsr   r5
>> +     clrrdi  r5,r5,1         /* Clear MSR_LE */
>> +     mtsrr1  r5
>> +
>> +     li      r5,0
>> +
>> +     rfid
> 
> Is kexec-lite meant to be specific to book3s-64?  The README just says "A 
> simple kexec for flattened device tree platforms" and I see a __powerpc64__ 
> ifdef in kexec_trampoline.S (but not in the above patch)...
> 
> -Scott
> 

I believe that particular ifdef is to check if we're little-endian when reading
the device tree, but that's still a good point - I'll check with Anton.

-- 
-----------
LTC Ozlabs
IBM

Re: [kexec-lite PATCH V2] trampoline: Reset primary cpu endian to big-endian

[Anton Blanchard]

Hi Scott,

> Is kexec-lite meant to be specific to book3s-64? 

It was originally built to test book3s-64 kexec. Likely some other
issues need fixing for other ppc sub arches, but it is nice to
have a very simple kexec.

Anton

Re: [kexec-lite PATCH V2] trampoline: Reset primary cpu endian to big-endian

[Scott Wood]

On Wed, 2015-07-08 at 13:49 +1000, Samuel Mendoza-Jonas wrote:
> On 08/07/15 13:37, Scott Wood wrote:
> > On Wed, 2015-07-08 at 13:29 +1000, Samuel Mendoza-Jonas wrote:
> > > Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
> > > meaning if we kexec from a little-endian kernel the target kernel will
> > > fail to boot.
> > > Returning to big-endian before we enter the target kernel ensures that
> > > the target kernel can boot whether or not it includes FIXUP_ENDIAN.
> > > 
> > > Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
> > > ---
> > > V2: As suggested by Anton take advantage of the rfid call and switch off
> > > MSR_LE and branch to the target kernel in the same step.
> > > 
> > >  kexec_trampoline.S | 11 +++++++++--
> > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/kexec_trampoline.S b/kexec_trampoline.S
> > > index a3eb314..3751112 100644
> > > --- a/kexec_trampoline.S
> > > +++ b/kexec_trampoline.S
> > > @@ -88,8 +88,15 @@ start:
> > >  
> > >       li      r5,0
> > >  
> > > -     mtctr   r4
> > > -     bctr
> > > +     mtsrr0  r4
> > > +
> > > +     mfmsr   r5
> > > +     clrrdi  r5,r5,1         /* Clear MSR_LE */
> > > +     mtsrr1  r5
> > > +
> > > +     li      r5,0
> > > +
> > > +     rfid
> > 
> > Is kexec-lite meant to be specific to book3s-64?  The README just says "A 
> > simple kexec for flattened device tree platforms" and I see a 
> > __powerpc64__ 
> > ifdef in kexec_trampoline.S (but not in the above patch)...
> > 
> > -Scott
> > 
> 
> I believe that particular ifdef is to check if we're little-endian when 
> reading
> the device tree, but that's still a good point - I'll check with Anton.

It looks like this ended up going into main kexec, which means I get to find 
some way to distinguish book3s from book3e to avoid that rfid.  Yay.

-Scott