[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-mips
Subject:    Re: [PATCH 6/9] MIPS: Call relocate_kernel if CONFIG_RELOCATABLE=y
From:       Matt Redfearn <matt.redfearn () imgtec ! com>
Date:       2015-12-04 8:20:05
Message-ID: 56614CB5.9020002 () imgtec ! com
[Download RAW message or body]

Hi James,

On 03/12/15 18:54, James Hogan wrote:
> On 3 December 2015 17:46:14 GMT+00:00, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote:
>> On 12/03/2015 05:53 PM, Matt Redfearn wrote:
>>
>>>>> If CONFIG_RELOCATABLE is enabled, jump to relocate_kernel.
>>>>>
>>>>> This function will return the entry point of the relocated kernel
>> if
>>>>> copy/relocate is sucessful or the original entry point if not. The
>> stack
>>>>> pointer must then be pointed into the new image.
>>>>>
>>>>> Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
>>>>> ---
>>>>>    arch/mips/kernel/head.S | 20 ++++++++++++++++++++
>>>>>    1 file changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
>>>>> index 4e4cc5b9a771..7dc043349d66 100644
>>>>> --- a/arch/mips/kernel/head.S
>>>>> +++ b/arch/mips/kernel/head.S
>>>>> @@ -132,7 +132,27 @@ not_found:
>>>>>        set_saved_sp    sp, t0, t1
>>>>>        PTR_SUBU    sp, 4 * SZREG        # init stack pointer
>>>>>
>>>>> +#ifdef CONFIG_RELOCATABLE
>>>>> +    /* Copy kernel and apply the relocations */
>>>>> +    jal        relocate_kernel
>>>>> +
>>>>> +    /* Repoint the sp into the new kernel image */
>>>>> +    PTR_LI        sp, _THREAD_SIZE - 32 - PT_SIZE
>>>>> +    PTR_ADDU    sp, $28
>>>>     Can't you account for it in the previous PTR_LI?
>>> During relocate_kernel, $28, pointer to the current thread,
>> Ah, it's a register! I thought it was an immediate. Nevermind then. :-)
> Although, it could still be reduced:
> PTR_ADDU sp, gp, _THREAD_SIZE - 32 - PT_SIZE
>
> Assuming the immediate is in range of signed 16bit.

The immediate would be 32552, so in range of signed 16bit, but that 
would be brittle if either _THREAD_SIZE or PT_SIZE were to change in 
future....

Thanks,
Matt
>
> Cheers
> James
>
>> [...]
>>
>> MBR, Sergei
>


[prev in list] [next in list] [prev in thread] [next in thread]