arm erratas (config options)

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

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 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.

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.)

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:

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

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.

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