[U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards

[Li.Xiubo at freescale.com]

Hi Albert,


> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.u.boot at aribaud.net]
> Sent: Friday, November 14, 2014 7:45 PM
> To: Xiubo Li-B47053
> Cc: Sun York-R58495; Jin Zhengxiong-R64188; u-boot at lists.denx.de
> Subject: Re: [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
> 
> Hello Li.Xiubo at freescale.com,
> 
> On Fri, 14 Nov 2014 09:06:13 +0000, Li.Xiubo at freescale.com
> <Li.Xiubo at freescale.com> wrote:
> > Hi Albert,
> >
> > > > +#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
> > > > +/* Setting the address at which secondary cores start from.*/
> > > > +void smp_set_core_boot_addr(unsigned long addr, int corenr)
> > > > +{
> > > > +	struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
> > > > +
> > > > +	/*
> > > > +	 * After setting the secondary cores start address,
> > > > +	 * just release them to boot.
> > > > +	 */
> > > > +	out_be32(&gur->scratchrw[0], addr);
> > > > +	out_be32(&gur->brrl, 0x2);
> > > > +}
> > >
> > > This function does not exactly "[set] the address at which secondary
> > > cores start from"; it sets *a* secondary core's boot address, and then
> > > it *boots* it.
> > >
> >
> > Okay, I will fix it later.
> >
> > > Why does this version of smp_set_core_boot_addr() need to boot the core
> > > in addition to setting the address, whereas the existing ones in
> > > virt_v7, vexpress_common and arndale don't boot the cores?
> > >
> >
> > Yes, they don't doing the release operation.
> >
> > For Low Power Management requirement, maybe only one core will be used, and
> then
> > We also make sure that the secondary core must be in low power and deep
> sleep
> > mode(using wfi). So I just release it here, to make sure that the wfi
> instruction
> > will be executed as early as possible.
> 
> Right after smp_set_core_boot_addr() is called, kick_all_cpus() isgoing
> to be called. Wouldn't that boot your CPUs just as well?
> 

Yes, it will.

But before that we must do the holdoff bit set operation as the SoC's requirement.

The BRR contains control bits for enabling boot for each core. On exiting HRESET or
PORESET, the RCW BOOT_HO field optionally allows for logical core 0 to be released
for booting or to remain in boot holdoff. All other cores remain in boot holdoff until their
corresponding bit is set.

Maybe the comment is not very clear and a bit confusing.

Thanks,

BRs
Xiubo

> > Thanks,
> >
> > BRs,
> > Xiubo
> 
> Amicalement,
> --
> Albert.