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

[Huan Wang]

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.


Best Regards,
Alison Wang