Cortex-A9 SCU + ARM_ERRATA_764369

Cortex-A9 SCU + ARM_ERRATA_764369

[Mason]

Hello,

I'm using a dual Cortex-A9 MPCore r3p0 setup.
Thus, I have selected the following ERRATA work-arounds:

	select ARM_ERRATA_754322
	select ARM_ERRATA_764369 if SMP
	select ARM_ERRATA_775420

(I hope I didn't miss any.)

config ARM_ERRATA_764369
	bool "ARM errata: Data cache line maintenance operation by MVA may not succeed"
	depends on CPU_V7 && SMP
	help
	  This option enables the workaround for erratum 764369
	  affecting Cortex-A9 MPCore with two or more processors (all
	  current revisions). Under certain timing circumstances, a data
	  cache line maintenance operation by MVA targeting an Inner
	  Shareable memory region may fail to proceed up to either the
	  Point of Coherency or to the Point of Unification of the
	  system. This workaround adds a DSB instruction before the
	  relevant cache maintenance functions and sets a specific bit
	  in the diagnostic control register of the SCU.

I'm confused by some code in scu_enable() introduced by commit f630c1bdfbf8f

#ifdef CONFIG_ARM_ERRATA_764369
	/* Cortex-A9 only */
	if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
		scu_ctrl = readl_relaxed(scu_base + 0x30);
		if (!(scu_ctrl & 1))
			writel_relaxed(scu_ctrl | 0x1, scu_base + 0x30);
	}
#endif

<confused>
What is scu_base + 0x30? (SCU diagnostic control register?)
I don't see this register/offset documented in
Cortex-A9 MPCore r3p0 Technical Reference Manual (2.2 SCU registers)

And what is bit0 in this register?

Regards.

Cortex-A9 SCU + ARM_ERRATA_764369

[Mark Rutland]

On Tue, Nov 03, 2015 at 05:51:40PM +0100, Mason wrote:
> Hello,
> 
> I'm using a dual Cortex-A9 MPCore r3p0 setup.
> Thus, I have selected the following ERRATA work-arounds:
> 
> 	select ARM_ERRATA_754322
> 	select ARM_ERRATA_764369 if SMP
> 	select ARM_ERRATA_775420
> 
> (I hope I didn't miss any.)
> 
> config ARM_ERRATA_764369
> 	bool "ARM errata: Data cache line maintenance operation by MVA may not succeed"
> 	depends on CPU_V7 && SMP
> 	help
> 	  This option enables the workaround for erratum 764369
> 	  affecting Cortex-A9 MPCore with two or more processors (all
> 	  current revisions). Under certain timing circumstances, a data
> 	  cache line maintenance operation by MVA targeting an Inner
> 	  Shareable memory region may fail to proceed up to either the
> 	  Point of Coherency or to the Point of Unification of the
> 	  system. This workaround adds a DSB instruction before the
> 	  relevant cache maintenance functions and sets a specific bit
> 	  in the diagnostic control register of the SCU.
> 
> I'm confused by some code in scu_enable() introduced by commit f630c1bdfbf8f
> 
> #ifdef CONFIG_ARM_ERRATA_764369
> 	/* Cortex-A9 only */
> 	if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
> 		scu_ctrl = readl_relaxed(scu_base + 0x30);
> 		if (!(scu_ctrl & 1))
> 			writel_relaxed(scu_ctrl | 0x1, scu_base + 0x30);
> 	}
> #endif
> 
> <confused>
> What is scu_base + 0x30? (SCU diagnostic control register?)
> I don't see this register/offset documented in
> Cortex-A9 MPCore r3p0 Technical Reference Manual (2.2 SCU registers)

It's documented (admittedly very sparsely) in the Software Developers
Errata Notice for Cortex-A9 processors, in the section regarding erratum
764369.

Thanks,
Mark.

Cortex-A9 SCU + ARM_ERRATA_764369

[Mason]

On 03/11/2015 18:27, Mark Rutland wrote:
> On Tue, Nov 03, 2015 at 05:51:40PM +0100, Mason wrote:
>> Hello,
>>
>> I'm using a dual Cortex-A9 MPCore r3p0 setup.
>> Thus, I have selected the following ERRATA work-arounds:
>>
>> 	select ARM_ERRATA_754322
>> 	select ARM_ERRATA_764369 if SMP
>> 	select ARM_ERRATA_775420
>>
>> (I hope I didn't miss any.)
>>
>> config ARM_ERRATA_764369
>> 	bool "ARM errata: Data cache line maintenance operation by MVA may not succeed"
>> 	depends on CPU_V7 && SMP
>> 	help
>> 	  This option enables the workaround for erratum 764369
>> 	  affecting Cortex-A9 MPCore with two or more processors (all
>> 	  current revisions). Under certain timing circumstances, a data
>> 	  cache line maintenance operation by MVA targeting an Inner
>> 	  Shareable memory region may fail to proceed up to either the
>> 	  Point of Coherency or to the Point of Unification of the
>> 	  system. This workaround adds a DSB instruction before the
>> 	  relevant cache maintenance functions and sets a specific bit
>> 	  in the diagnostic control register of the SCU.
>>
>> I'm confused by some code in scu_enable() introduced by commit f630c1bdfbf8f
>>
>> #ifdef CONFIG_ARM_ERRATA_764369
>> 	/* Cortex-A9 only */
>> 	if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
>> 		scu_ctrl = readl_relaxed(scu_base + 0x30);
>> 		if (!(scu_ctrl & 1))
>> 			writel_relaxed(scu_ctrl | 0x1, scu_base + 0x30);
>> 	}
>> #endif
>>
>> <confused>
>> What is scu_base + 0x30? (SCU diagnostic control register?)
>> I don't see this register/offset documented in
>> Cortex-A9 MPCore r3p0 Technical Reference Manual (2.2 SCU registers)
> 
> It's documented (admittedly very sparsely) in the Software Developers
> Errata Notice for Cortex-A9 processors, in the section regarding erratum
> 764369.

Sigh. ARM documentation is such a treasure hunt experience.

Errata Notices are not freely available, thus probably not
indexed by search engines.

The other day, I couldn't find what I was looking for in the
A9MPC TRM, because it was in the A9 TRM. And I suspect the
architected registers are only documented in the ARM ARM.

Regards.

Related discussion for my own reference:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/313051

Cortex-A9 SCU + ARM_ERRATA_764369

[Russell King - ARM Linux]

On Tue, Nov 03, 2015 at 07:55:10PM +0100, Mason wrote:
> Sigh. ARM documentation is such a treasure hunt experience.

It's not that bad, though I do hate the ARM ARM organisation.  I wish
it was split up into a series of stand-alone documents instead of one
huge one - though one huge document does have the advantage of being
trivially searchable.

> Errata Notices are not freely available, thus probably not
> indexed by search engines.
> 
> The other day, I couldn't find what I was looking for in the
> A9MPC TRM, because it was in the A9 TRM. And I suspect the
> architected registers are only documented in the ARM ARM.

Right, so what you do is you download a copy of the PDFs for the Cortex A9
and the ARM ARM, and then either use pdftotext to generate text versions
of them you can grep through, or open each and search through each document
individually.

When you've been working with ARM stuff for a while, you get to know to
start at the ARM ARM, and work upwards to more specific documents - or,
you get to know what kind of information is in which class of document
and then you can go straight to the appropriate doc.

Trust me, the documentation that ARM produces is really nice compared to
the documents that many silicon vendors produce - many of which aren't
worth downloading.  Many barely manage to describe any bit in various
registers adequately, and you're left to experiment by trial and error.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Cortex-A9 SCU + ARM_ERRATA_764369

[Mason]

Mark Rutland wrote:

> Mason wrote:
>
>> What is scu_base + 0x30? (SCU diagnostic control register?)
> 
> It's documented (admittedly very sparsely) in the Software
> Developers Errata Notice for Cortex-A9 processors, in the
> section regarding erratum 764369.

A Freescale document mentions:

> Set bit[0] in the undocumented SCU diagnostic control register
> located at offset 0x30 from the PERIPHBASE address. Setting this bit
> disables the "migratory bit" feature. This forces a dirty cache line
> to be evicted to the lower memory subsystem?which is both the point
> of coherency and the point of unification?when it is being read by
> another processor.

Can this register be written to by a non-secure OS?

Regards.

Cortex-A9 SCU + ARM_ERRATA_764369

[Mason]

On 03/11/2015 20:52, Mason wrote:

> Mark Rutland wrote:
> 
>> Mason wrote:
>>
>>> What is scu_base + 0x30? (SCU diagnostic control register?)
>>
>> It's documented (admittedly very sparsely) in the Software
>> Developers Errata Notice for Cortex-A9 processors, in the
>> section regarding erratum 764369.
> 
> A Freescale document mentions:
> 
>> Set bit[0] in the undocumented SCU diagnostic control register
>> located at offset 0x30 from the PERIPHBASE address. Setting this bit
>> disables the "migratory bit" feature. This forces a dirty cache line
>> to be evicted to the lower memory subsystem?which is both the point
>> of coherency and the point of unification?when it is being read by
>> another processor.
> 
> Can this register be written to by a non-secure OS?

IIUC Rob's message, NS OS cannot write to scu_base + 0x30.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244341.html

<confused> Rob stated:
"these types of work-arounds must go into the bootloader or firmware."

Doesn't that apply to 764369 too? (At least the part setting
bit0 in scu_base + 0x30)

If a company is not using a standard boot-loader such as U-Boot,
does that mean it must re-implement all these work-arounds in
its own boot-loader?

Does firmware mean secure OS?

Regards.

Cortex-A9 SCU + ARM_ERRATA_764369

[Mason]

On 03/11/2015 21:36, Mason wrote:

> On 03/11/2015 20:52, Mason wrote:
> 
>> Mark Rutland wrote:
>>
>>> Mason wrote:
>>>
>>>> What is scu_base + 0x30? (SCU diagnostic control register?)
>>>
>>> It's documented (admittedly very sparsely) in the Software
>>> Developers Errata Notice for Cortex-A9 processors, in the
>>> section regarding erratum 764369.
>>
>> A Freescale document mentions:
>>
>>> Set bit[0] in the undocumented SCU diagnostic control register
>>> located at offset 0x30 from the PERIPHBASE address. Setting this bit
>>> disables the "migratory bit" feature. This forces a dirty cache line
>>> to be evicted to the lower memory subsystem?which is both the point
>>> of coherency and the point of unification?when it is being read by
>>> another processor.
>>
>> Can this register be written to by a non-secure OS?
> 
> IIUC Rob's message, NS OS cannot write to scu_base + 0x30.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244341.html
> 
> <confused> Rob stated:
> "these types of work-arounds must go into the bootloader or firmware."
> 
> Doesn't that apply to 764369 too? (At least the part setting
> bit0 in scu_base + 0x30)
> 
> If a company is not using a standard boot-loader such as U-Boot,
> does that mean it must re-implement all these work-arounds in
> its own boot-loader?

AFAICT, U-Boot implements the following work-arounds.
http://git.denx.de/?p=u-boot.git;a=blob;f=README

	CONFIG_ARM_ERRATA_716044
	CONFIG_ARM_ERRATA_742230
	CONFIG_ARM_ERRATA_743622
	CONFIG_ARM_ERRATA_751472
	CONFIG_ARM_ERRATA_761320
	CONFIG_ARM_ERRATA_773022
	CONFIG_ARM_ERRATA_774769
	CONFIG_ARM_ERRATA_794072

I'll have to talk to the boot-loader and secure OS devs.

Regards.