On Wed, May 7, 2014 at 2:05 AM, Marc Zyngier <marc.zyng...@arm.com> wrote: > On Fri, May 02 2014 at 10:03:37 pm BST, Jon Loeliger <loeli...@gmail.com> > wrote: >> Mark, >> >> In your nonsec_init code, you suggest this change: >> >> + mrc p15, 0, r0, c1, c1, 2 >> movw r1, #0x3fff >> - movt r1, #0x0006 >> - mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros to >> non-sec >> + movt r1, #0x0004 >> + orr r0, r0, r1 >> + mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to >> non-sec >> >> Leaving: >> >> mrc p15, 0, r0, c1, c1, 2 >> movw r1, #0x3fff >> movt r1, #0x0004 >> orr r0, r0, r1 >> mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to >> non-sec >> >> That sets all the co-processor bits, but the man page suggests that only > > Just to be clear: which document are you referring to?
Hmm... Lessee.. Uh, this one: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388i/CIHEAIAJ.html So, Cortex-A9 TRM 4.3.13 That one happens to be r4p1, but the description is the same for my part rev (r2p9, IIRC). Anyway, those low bits are marked as UNK/SBZP, hence my concern for the apparent extra ON bits. >> copros with bits 10 and 11 should be modified. It also seems that if the > > The ARM ARM says that NSACR[13:0] is either RAZ/WI or writable from > secure for unimplemented coprocessors. The ARM ARM uber alles. :-) > So I believe the above is > safe. If you wanted to be really picky, you'd start by reading CPACR, > write either 1 or 3 to all the CPn fields, read it back again, see what > sticks, and populate NSACR accordingly. Did I hear someone saying > "Boring"? ;-) I'm sorry, did you say something? Sounded like you said "Waw-waw waw-wah CPn waw ..." >> PLE is enabled, we should mark it NS-enabled at bit 16 also:. Perhaps: >> >> mrc p15, 0, r0, c1, c1, 2 >> movw r1, #0x0c00 >> movt r1, #0x0005 >> orr r0, r0, r1 >> mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec > > We're getting into IMPDEF territory pretty quickly here. PLE only exists > on A9, and is optionnal there (and probably doesn't exist on all > versions, if memory serves well...). Ah. Gotcha. Blah blah Osprey ah-chew! Gesundheit! > This could be implemented as a per-platform optional feature, > though. What do you think? I think we should all convert to A57 on a Dickens ring and be done. In the meantime, it's likely not worth it to be this picky about the darn PLE bits, nor the rest of the NSACR bits. Especially if the ARM ARM says we can let it slide. > M. > -- > Without deviation from the norm, progress is not possible. Yes, yes, Everybody got to deviate from the norm. jdl On Wed, May 7, 2014 at 2:05 AM, Marc Zyngier <marc.zyng...@arm.com> wrote: > On Fri, May 02 2014 at 10:03:37 pm BST, Jon Loeliger <loeli...@gmail.com> > wrote: >> Mark, >> >> In your nonsec_init code, you suggest this change: >> >> + mrc p15, 0, r0, c1, c1, 2 >> movw r1, #0x3fff >> - movt r1, #0x0006 >> - mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros to >> non-sec >> + movt r1, #0x0004 >> + orr r0, r0, r1 >> + mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to >> non-sec >> >> Leaving: >> >> mrc p15, 0, r0, c1, c1, 2 >> movw r1, #0x3fff >> movt r1, #0x0004 >> orr r0, r0, r1 >> mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to >> non-sec >> >> That sets all the co-processor bits, but the man page suggests that only > > Just to be clear: which document are you referring to? > >> copros with bits 10 and 11 should be modified. It also seems that if the > > The ARM ARM says that NSACR[13:0] is either RAZ/WI or writable from > secure for unimplemented coprocessors. So I believe the above is > safe. If you wanted to be really picky, you'd start by reading CPACR, > write either 1 or 3 to all the CPn fields, read it back again, see what > sticks, and populate NSACR accordingly. Did I hear someone saying > "Boring"? ;-) > >> PLE is enabled, we should mark it NS-enabled at bit 16 also:. Perhaps: >> >> mrc p15, 0, r0, c1, c1, 2 >> movw r1, #0x0c00 >> movt r1, #0x0005 >> orr r0, r0, r1 >> mcr p15, 0, r0, c1, c1, 2 @ NSACR = all copros to non-sec > > We're getting into IMPDEF territory pretty quickly here. PLE only exists > on A9, and is optionnal there (and probably doesn't exist on all > versions, if memory serves well...). > > This could be implemented as a per-platform optional feature, > though. What do you think? > > M. > -- > Without deviation from the norm, progress is not possible. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
