[bootwrapper PATCH] aarch64: Enable BRBE for the non-secure world

Mark Rutland mark.rutland at arm.com
Tue Jan 18 02:34:29 PST 2022


On Tue, Jan 18, 2022 at 08:12:39AM +0530, Anshuman Khandual wrote:
> On 1/17/22 6:55 PM, Mark Rutland wrote:
> > On Mon, Jan 17, 2022 at 04:06:44PM +0530, Anshuman Khandual wrote:
> >> On 1/13/22 3:54 PM, Mark Rutland wrote:
> >>> On Thu, Jan 13, 2022 at 03:11:08PM +0530, Anshuman Khandual wrote:
> >>>> +1:	mrs     x1, id_aa64dfr0_el1
> >>>> +	ubfx    x1, x1, #52, #4
> >>>> +	cbz     x1, 1f
> >>>> +
> >>>> +	// Enable BRBE for the non-secure world.
> >>>> +	ldr     x1, =(0x3 << 32)
> >>>> +	orr     x0, x0, x1
> >>>> +
> >>>
> >>> I assume this is the `SBRBE` field, which naming-wise sounds like it controls
> >>> Secure rather than Non-Secure (e,g. by way of comparison to `NSPB`). Is that
> >>
> >> Right, that is some what counter-intuitive.
> >>
> >>> correct? What effect does the value 0x3 have?
> >>
> >> As per the definition above.
> >>
> >> 0b11	 This control does not cause any direct accesses to BRBE registers or
> >>          instruction to be trapped, and does not cause any Exception levels to
> >> 	 be a prohibited region.
> >>
> >> This basically allows BRBE usage in EL2/EL1.
> > 
> > Thanks for this!
> > 
> > Just to check, my understanding, there's nothing else that we need to
> > initialize to ensure that BRBE won't start recording unexpectedly
> > out-of-reset, becuase in BRBCR_EL* the E*BRE bits all warm-reset to 0
> > and hence prevent recording in any of EL0/EL1/EL2 (and BRBE never
> > records at EL3). Is that right?
> 
> Right, that is my understanding as well. Those required bits that start
> BRBE recording, always warm-reset to 0.

Thanks for confirming!

I've applied this and pushed it out.

Mark.



More information about the linux-arm-kernel mailing list