recent ARM Erratas 742231 & 742230 broken.

recent ARM Erratas 742231 & 742230 broken.

[Srinidhi KASAGAR]

Will,

Are the below ERRATAs (in linux-next) on Cortex-A9 have been tested with
booting in non secure mode?

commit 9f05027c7cb3cfe56a31892bd83391138d41a667
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Sep 14 09:51:43 2010 +0100

    ARM: 6388/1: errata: DMB operation may be faulty

    On versions of the Cortex-A9 up to and including r2p2, under rare
    circumstances, a DMB instruction between 2 write operations may not
    ensure the correct visibility ordering of the 2 writes.

    This workaround sets a bit in the diagnostic register of the Cortex-A9,
    causing the DMB instruction to behave like a DSB, which functions
    correctly on the affected cores.

and

commit a672e99b129e286df2e2697a1b603d82321117f3
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Sep 14 09:53:02 2010 +0100

    ARM: 6389/1: errata: incorrect hazard handling in the SCU may lead
to data corruption

    On the r2p0, r2p1 and r2p2 versions of the Cortex-A9, data corruption
    can occur if a shared cache line is replaced on one CPU as another CPU
    is accessing it.

    This workaround sets two bits in the diagnostic register of the Cortex-A9,
    reducing the linefill issuing capabilities of the processor and
    avoiding the erroneous behaviour.

What I see is that when I try to boot the system having this version
of Cortex-A9 I see
that the system does not boot at all. These diagnostic registers which seems
undocumented and unable to see what's going on. However the system boots if I
start from secure mode.

Srinidhi

recent ARM Erratas 742231 & 742230 broken.

[Will Deacon]

Hi Srinidhi,

> Are the below ERRATAs (in linux-next) on Cortex-A9 have been tested with
> booting in non secure mode?
> 
> commit 9f05027c7cb3cfe56a31892bd83391138d41a667
> Author: Will Deacon <will.deacon@arm.com>
> Date:   Tue Sep 14 09:51:43 2010 +0100
> 
>     ARM: 6388/1: errata: DMB operation may be faulty

[...]

> commit a672e99b129e286df2e2697a1b603d82321117f3
> Author: Will Deacon <will.deacon@arm.com>
> Date:   Tue Sep 14 09:53:02 2010 +0100
> 
>     ARM: 6389/1: errata: incorrect hazard handling in the SCU may lead
> to data corruption

[...]

> 
> What I see is that when I try to boot the system having this version
> of Cortex-A9 I see
> that the system does not boot at all. These diagnostic registers which seems
> undocumented and unable to see what's going on. However the system boots if I
> start from secure mode.

The diagnostic register is only writable from secure mode so you'll need to
look at what these patches do (they perform simple read-modify-writes) and
incorporate that code into your secure software. You will then need to ensure
that you don't have the workarounds enabled in the Kernel. Note that not
all revisions of the A9 are affected by these problems so you might not
need to implement both of the workarounds (the patches above check the MIDR).

I doubt that your secure monitor exposes the diagnostic register through an
SMC interface so you'll need to change the secure boot code to enable these
workarounds when the system comes out of reset.

I hope that helps,

Will

recent ARM Erratas 742231 & 742230 broken.

[Linus Walleij]

2010/10/20 Will Deacon <will.deacon@arm.com>:

> The diagnostic register is only writable from secure mode so you'll need to
> look at what these patches do (they perform simple read-modify-writes) and
> incorporate that code into your secure software.
> (...)
> I doubt that your secure monitor exposes the diagnostic register through an
> SMC interface so you'll need to change the secure boot code to enable these
> workarounds when the system comes out of reset.

These SMC:s (System Management Call?) are getting hairier now.

Can't you add an abstraction for the stuff we need to poke into
diagnostics registers, enabling platform-specific overrides, like
we do for l2x0 in mm/cache-l2x0.c?

Like if arch/arm/include/asm/proc-v7-diagnostics.h:
(modeled on arch/arm/include/asm/outercache.h)

struct v7_core_diagnostics {
  void (*foo)(void);
  void (*bar)(void);
};

Then we can override thes during .machine_init or even .fixup if
it's needed real early on.

This way each platform (including I think U8500 and OMAP4) can respond
correctly to the errata patches once we have proper SMCs in place.

Yours,
Linus Walleij

recent ARM Erratas 742231 & 742230 broken.

[Russell King - ARM Linux]

On Fri, Nov 05, 2010 at 01:12:48PM +0100, Linus Walleij wrote:
> 2010/10/20 Will Deacon <will.deacon@arm.com>:
> 
> > The diagnostic register is only writable from secure mode so you'll need to
> > look at what these patches do (they perform simple read-modify-writes) and
> > incorporate that code into your secure software.
> > (...)
> > I doubt that your secure monitor exposes the diagnostic register through an
> > SMC interface so you'll need to change the secure boot code to enable these
> > workarounds when the system comes out of reset.
> 
> These SMC:s (System Management Call?) are getting hairier now.
> 
> Can't you add an abstraction for the stuff we need to poke into
> diagnostics registers, enabling platform-specific overrides, like
> we do for l2x0 in mm/cache-l2x0.c?

That's a subject which came up when the first errata were merged.  The
fact of the matter is that there's no easy way to abstract the assembly
code - it certainly can't become C code because we don't have the MMU
up and running at this point.

Running the kernel in non-secure mode is going to be painful because of
(a) the need to issue SMC calls to access protected registers, and (b)
the lack of an API for the SMC call.

(a) isn't going to change, and (b) apparantly isn't something we can
influence.

The approach generally taken by proc-v7 is to check whether the work-
around is already enabled, and if it is, it skips trying to enable it
a second time, thereby avoiding aborts etc.

So the responsibility for enabling the protected work-arounds lies with
code which has access to the registers.

recent ARM Erratas 742231 & 742230 broken.

[Will Deacon]

Hey Linus,

> 2010/10/20 Will Deacon <will.deacon@arm.com>:
> 
> > The diagnostic register is only writable from secure mode so you'll need to
> > look at what these patches do (they perform simple read-modify-writes) and
> > incorporate that code into your secure software.
> > (...)
> > I doubt that your secure monitor exposes the diagnostic register through an
> > SMC interface so you'll need to change the secure boot code to enable these
> > workarounds when the system comes out of reset.
> 
> These SMC:s (System Management Call?) are getting hairier now.

Secure Monitor Call :)

What I was eluding to above is that exposing things like the diagnostic
register via an SMC is a *really* bad idea.  It's much better to set /clear
any necessary bits in the secure boot code and then be done with it.
If that's not possible, you could have a bunch of per-erratum SMCs
but if you can modify the monitor in such a way then you should be able
to modify the boot code too.
 
> Can't you add an abstraction for the stuff we need to poke into
> diagnostics registers, enabling platform-specific overrides, like
> we do for l2x0 in mm/cache-l2x0.c?

I think Russell addressed this point.

Cheers,

Will