[U-Boot] [RESEND PATCH v14 07/10] arm64: core support

[Scott Wood]

On Fri, 2013-11-08 at 13:49 +0800, FengHua wrote:
> > -----原始邮件-----
> > 发件人: "Scott Wood" <scottwood at freescale.com>
> > 发送时间: 2013-11-08 08:44:34 (星期五)
> > 收件人: fenghua at phytium.com.cn
> > 抄送: u-boot at lists.denx.de, trini at ti.com, albert.u.boot at aribaud.net
> > 主题: Re: [RESEND PATCH v14 07/10] arm64: core support
> > 
> > On Tue, 2013-10-15 at 11:34 +0800, fenghua at phytium.com.cn wrote:
> > > +/*
> > > + * void __asm_flush_dcache_level(level)
> > > + *
> > > + * clean and invalidate one level cache.
> > > + *
> > > + * x0: cache level
> > > + * x1~x9: clobbered
> > > + */
> > > +ENTRY(__asm_flush_dcache_level)
> > > +	lsl	x1, x0, #1
> > > +	msr	csselr_el1, x1		/* select cache level */
> > > +	isb				/* isb to sych the new cssr & csidr */
> > > +	mrs	x6, ccsidr_el1		/* read the new ccsidr */
> > > +	and	x2, x6, #7		/* x2 <- length of the cache lines */
> > > +	add	x2, x2, #4		/* add 4 (line length offset) */
> > > +	mov	x3, #0x3ff
> > > +	and	x3, x3, x6, lsr #3	/* x3 <- maximum number of way size */
> > > +	clz	w5, w3			/* bit position of way size */
> > 
> > You should round up (so "add w3, w3, w3; sub w3, w3, #1" before clz),
> > since the architecture allows non-power-of-2 values for #sets/#ways.
> > 
> x3 is the way size after "and	x3, x3, x6, lsr #3".
> "clz	w5, w3" is used to caculate the number of heading zero  of way size.
> The result will be used to generate parameter of "dc cisw".
> we don't need to calculate the power-of-2 values for #ways.

According to the manual, the number of bits for the "way" field is
log2(associativity) rounded up to the nearest integer.  Counting the
leading zeroes does not round up -- you'll get the same number of
leading zeroes for e.g. 0x17 as for 0x10.

> > BTW, I see some very similar comments, register usage, and code
> > structure in the Linux code.  Are you *sure* this code wasn't derived
> > from it (or some other common source)?  Do we need to start from
> > scratch, if we can't trust that you're identifying all the code that you
> > didn't write yourself?  You were asked several times to do so.
> > 
> The reference code is from ARMv8 ARM.

That still counts as code that came from somewhere else that needs to be
attributed.  What is the license on that code in the ARMv8 ARM?

Plus, I see some other similarities to the Linux code that aren't found
in the ARMv8 ARM code (e.g. "add 4 (line length offset)", "create
working copy of [max] way size"...).

> Cache.S of Linux-aarch64 is identical with it.
> Maybe the maintainer of Linux-aarch64 is just the writer of ARMv8 ARM.

There is an ARM copyright on that file in Linux...

> It's hard to write different code to do hardware specific initialization.

I'm not necessarily asking for different code, just attribution and
license compliance.

> > > +	/* load TTBR0 */
> > > +	el = curent_el();
> > > +	if (el == 1)
> > > +		asm volatile("msr ttbr0_el1, %0"
> > > +			     : : "r" (gd->arch.tlb_addr) : "memory");
> > > +	else if (el == 2)
> > > +		asm volatile("msr ttbr0_el2, %0"
> > > +			     : : "r" (gd->arch.tlb_addr) : "memory");
> > > +	else
> > > +		panic("Not Supported Exception Level");
> > 
> > Do we really need to support running in either el1 or el2 at runtime,
> > throughout U-Boot?  If Linux is started in el2, it enters el1 after
> > setting up exception vectors to get control back if it needs to.  Can't
> > we do the same (and go back to el2 if available immediately before
> > entering an OS)?  Assuming we don't want to just set the expected
> > exception level at compile time.
> > 
> I am preparing to ask for some advice about boot process.
> My original idea is to providing more choice for users. user could choose
> to run u-boot at el1 or el2.
> But now, locally I have changed the boot process. U-boot will be running
> at the highest exception level processor supportted (EL3/EL2/EL1)

By highest you mean closest to EL3?  That seems the opposite direction
of what would simplify things...

> I am not sure whether u-boot is ever used to provide run-time service before.

Only to standalone programs, not after booting an OS with bootm.

> There are many works to do if we want it be that.

We don't. :-)

-Scott