arm erratas (config options)

arm erratas (config options)

[Alexander Holler]

Hello,

I'm currious why there exists config options for the various arm 
erratas. Isn't it possible to identify the variant and revision of the 
cores and enable the necessary workarounds automatically?

And would it be possible to use only one term (at least inside the 
kernel) to describe the arm-variations?

E.g. /proc/cpuinfo talks about variant and revision while all the help 
texts for the erratas are talking about rNpM (which I would translate to 
"revision" and "patch level", without knowing the real meanings).

This makes it necessary to translate "variant" to 'r' and "revision" to 
'p', which isn't really obvious (because most people would translate 
"revision" to 'r' and would wonder how to find the value for 'p' in 
/proc/cpuinfo or somewhere else).

Another source of confusion about which arm erratas should be enabled 
for a specific processor is that not all the help texts for the erratas 
are clear about which variants and revisions are effected. E.g. the help 
texts for erratas 460075 or 458693 are talking about r2p0, but they 
doesn't mention if older variants (e.g. r1p3) get hit by these erratas 
too. The help texts for other erratas (e.g. 743622 and 754322) are 
talking about r2p*, which I would interpret that this errata applies 
only to variant 2, but I would never be sure (reading only the help text).

So without actually reading the erratas (and not only the help texts) I 
assume most people, including me ;) , just don't know if it's necessary 
to enable the workaround for a specific errata (besides that people 
would need to understand whats written in the erratas or help texts itself).

Just enabling all workarounds can't be the answer, otherwise the config 
options for those erratas wouldn't be necessary at all.

Assuming that the list of erratas will grow further, the problem will 
just get worse if nobody defines some rules about how the help texts 
should be written to leave no questions about when one has to enable an 
option.

Just my 2?. ;)

Regards,

Alexander

arm erratas (config options)

[Russell King - ARM Linux]

On Fri, Jun 22, 2012 at 12:05:44PM +0200, Alexander Holler wrote:
> E.g. /proc/cpuinfo talks about variant and revision while all the help  
> texts for the erratas are talking about rNpM (which I would translate to  
> "revision" and "patch level", without knowing the real meanings).

rNpM is a hardware thing.  On the test chips which ARM Ltd supply on
their platforms, it's marked on the case.  With SoC vendors, the only
way to know this definitively is to ask them.

> This makes it necessary to translate "variant" to 'r' and "revision" to  
> 'p', which isn't really obvious (because most people would translate  
> "revision" to 'r' and would wonder how to find the value for 'p' in  
> /proc/cpuinfo or somewhere else).

The variant and revision are terms used in the ARM ARM (or was used at
some point) which don't always reflect the rNpM marking on the package.
Sometimes, a hardware change is made which updates the rNpM but doesn't
update the ID registers.  So they can't be relied upon.

> Another source of confusion about which arm erratas should be enabled  
> for a specific processor is that not all the help texts for the erratas  
> are clear about which variants and revisions are effected. E.g. the help  
> texts for erratas 460075 or 458693 are talking about r2p0, but they  
> doesn't mention if older variants (e.g. r1p3) get hit by these erratas  
> too. The help texts for other erratas (e.g. 743622 and 754322) are  
> talking about r2p*, which I would interpret that this errata applies  
> only to variant 2, but I would never be sure (reading only the help 
> text).

You can enable them all, and the kernel will (attempt) to apply those
which are applicable to your CPU based on the ID register and the values
we know for the ID register corresponding to a particular rNpM part.

The reason they are configuration options is so that you can disable
them and remove that code from the kernel if you wish (and you know
they don't apply) or if you have an explicit need to disable them (you
want to run a test case, or you know that the kernel itself can't apply
the work-around because you're running in non-secure mode.)

arm erratas (config options)

[Alexander Holler]

Hello,

I made a full quote (as copy for others) because I find the answers very 
enlighting ;)

Am 22.06.2012 12:35, schrieb Russell King - ARM Linux:
> On Fri, Jun 22, 2012 at 12:05:44PM +0200, Alexander Holler wrote:
>> E.g. /proc/cpuinfo talks about variant and revision while all the help
>> texts for the erratas are talking about rNpM (which I would translate to
>> "revision" and "patch level", without knowing the real meanings).
>
> rNpM is a hardware thing.  On the test chips which ARM Ltd supply on
> their platforms, it's marked on the case.  With SoC vendors, the only
> way to know this definitively is to ask them.
>
>> This makes it necessary to translate "variant" to 'r' and "revision" to
>> 'p', which isn't really obvious (because most people would translate
>> "revision" to 'r' and would wonder how to find the value for 'p' in
>> /proc/cpuinfo or somewhere else).
>
> The variant and revision are terms used in the ARM ARM (or was used at
> some point) which don't always reflect the rNpM marking on the package.
> Sometimes, a hardware change is made which updates the rNpM but doesn't
> update the ID registers.  So they can't be relied upon.
>
>> Another source of confusion about which arm erratas should be enabled
>> for a specific processor is that not all the help texts for the erratas
>> are clear about which variants and revisions are effected. E.g. the help
>> texts for erratas 460075 or 458693 are talking about r2p0, but they
>> doesn't mention if older variants (e.g. r1p3) get hit by these erratas
>> too. The help texts for other erratas (e.g. 743622 and 754322) are
>> talking about r2p*, which I would interpret that this errata applies
>> only to variant 2, but I would never be sure (reading only the help
>> text).
>
> You can enable them all, and the kernel will (attempt) to apply those
> which are applicable to your CPU based on the ID register and the values
> we know for the ID register corresponding to a particular rNpM part.
>
> The reason they are configuration options is so that you can disable
> them and remove that code from the kernel if you wish (and you know
> they don't apply) or if you have an explicit need to disable them (you
> want to run a test case, or you know that the kernel itself can't apply
> the work-around because you're running in non-secure mode.)

Hmm, because some of the workarounds sound scary (when thinking about 
performance), I would prefer just to not see them for not getting 
tempted to disable the workarounds, even if I should know it better. ;)

Thanks for the answer which explains everything.

Regards,

Alexander

arm erratas (config options)

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Fri, Jun 22, 2012 at 12:05:44PM +0200, Alexander Holler wrote:
>> E.g. /proc/cpuinfo talks about variant and revision while all the help  
>> texts for the erratas are talking about rNpM (which I would translate to  
>> "revision" and "patch level", without knowing the real meanings).
>
> rNpM is a hardware thing.  On the test chips which ARM Ltd supply on
> their platforms, it's marked on the case.  With SoC vendors, the only
> way to know this definitively is to ask them.

The N and M values are contained in the main ID register on any core
with a standard CP15 system control interface.  Occasionally, an
implementation will have incorrect values here, e.g. (some?) Samsung
Exynos4 chips, and don't ask me how that happens, but most of the time
these values are reliable.

The fields in /proc/cpuinfo are indeed populated from the ID register.
The raw value of the ID register is also printed to the kernel log early
on.

>> This makes it necessary to translate "variant" to 'r' and "revision" to  
>> 'p', which isn't really obvious (because most people would translate  
>> "revision" to 'r' and would wonder how to find the value for 'p' in  
>> /proc/cpuinfo or somewhere else).
>
> The variant and revision are terms used in the ARM ARM (or was used at
> some point) which don't always reflect the rNpM marking on the package.
> Sometimes, a hardware change is made which updates the rNpM but doesn't
> update the ID registers.  So they can't be relied upon.

The ARM ARM refers to the version fields in the main ID register as
"variant" and "revision" without assigning any specific meaning to
them beyond noting that "typically, [the variant] field distinguishes
between different product variants, or major revisions of a product."

The rNpM versioning scheme is commonly used by ARM, not only for CPU
cores.  The mapping of these versions to ID register fields is
unfortunately a little confusing, as you have noted.

-- 
M?ns Rullg?rd
mans at mansr.com