[U-Boot] [u-boot] [PATCH] arm: sleep: Get the entry point of kernel from SPARE4 register

[Scott Wood]

On 04/07/2016 04:11 AM, Huan Wang wrote:
> Hi, Scott,
> 
>> On 04/05/2016 09:16 PM, Huan Wang wrote:
>>> Hi, York and Scott,
>>>
>>>> On 04/05/2016 05:11 AM, Alison Wang wrote:
>>>>> For LS1021A Secure Boot, SPARE2 register is used and modified by the
>>>>> IBR. To avoid the conflict, SPARE4 is used instead of SPARE2 to
>>>>> store the entry point of kernel. This patch is to get the entry
>>>>> point of kernel from SPARE4 instead of SPARE2.
>>>>>
>>>>> Signed-off-by: Alison Wang <alison.wang at nxp.com>
>>>>> ---
>>>>>  board/freescale/common/arm_sleep.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/board/freescale/common/arm_sleep.c
>>>>> b/board/freescale/common/arm_sleep.c
>>>>> index 71ed15e..6d967f0 100644
>>>>> --- a/board/freescale/common/arm_sleep.c
>>>>> +++ b/board/freescale/common/arm_sleep.c
>>>>> @@ -88,7 +88,7 @@ int fsl_dp_resume(void)
>>>>>  	dp_resume_prepare();
>>>>>
>>>>>  	/* Get the entry address and jump to kernel */
>>>>> -	start_addr = in_le32(&scfg->sparecr[1]);
>>>>> +	start_addr = in_le32(&scfg->sparecr[3]);
>>>>>  	debug("Entry address is 0x%08x\n", start_addr);
>>>>>  	kernel_resume = (void (*)(void))start_addr;
>>>>>  	secure_ram_addr(_do_nonsec_entry)(kernel_resume, 0, 0, 0);
>>>>>
>>>> Alison,
>>>>
>>>> Does this change need to be in sync with Kernel change?
>>>>
>>>> York
>>>>
>>>> Where does this get written?
>>>>
>>>> -Scott
>>> [Alison Wang] Thanks for your replies. Your concerns are right.
>>> SPARE4 register needs to be written in kernel.
>>>
>>> This is an issue about deep sleep in LS1021A Secure Boot. It is found
>>> in SDK2.0. The corresponding patch for kernel is sent in SDK2.0.
>>>
>>> Well, deep sleep uses an old way in SDK2.0. For upstream, deep sleep
>>> patches haven't been sent out as it will use PSCI and there are some
>>> issues about PSCI. So the corresponding patch for kernel can't be sent
>>> out now.
>>
>> It's not about when the patch is sent.  It's about managing
>> compatibility.  There needs to be some way to communicate what the
>> expectations are between Linux and U-Boot, or to limit the change to
>> chips where this feature has never worked before.  We can't introduce
>> regressions when the kernel is updated but not U-Boot, and regressions
>> when U-Boot is updated but not the kernel are almost as bad.
>>
>> -Scott
> [Alison Wang] Thanks for your advice. What you said is right. I will give up
> this patch in upstream now. Later, when the deep sleep patches for kernel is
> ready, I will fix the issue in U-Boot and kernel simultaneously. So there isn't
> any problem about the compatibility between U-Boot and kernel.

Please reread what I wrote.  Fixing them simultaneously doesn't solve
the problem because there's no guarantee that users update
simultaneously.  For a particularly bad example, consider someone
bisecting the kernel.  It would be terrible to require that the boot
firmware be reflashed every time the kernel crosses this boundary.

-Scott