[U-Boot] [PATCH V3 0/11] ARM: OMAP3-DRA7: CP15 erratum workarounds and improvements

[Siarhei Siamashka <siarhei.siamashka@gmail.com>]

On Mon, 2 Mar 2015 16:16:08 -0500
Tom Rini <trini@konsulko.com> wrote:

> On Thu, Feb 26, 2015 at 06:14:25PM +0200, Siarhei Siamashka wrote:
> > On Thu, 26 Feb 2015 08:50:09 -0600
> > Nishanth Menon <nm@ti.com> wrote:
> > 
> > > On Thu, Feb 26, 2015 at 1:40 AM, Siarhei Siamashka
> > > <siarhei.siamashka@gmail.com> wrote:
> > > > On Wed, 25 Feb 2015 14:55:08 -0600
> > > > Nishanth Menon <nm@ti.com> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> The third incarnation of this series to address various ideas of
> > > >> previous V2 series. I will skip the full blurb and point to V1/V2
> > > >> links for the usual blurb.
> > > >>
> > > >> Changes since V2:
> > > >>       - Added documentation revisioning info with ARM erratums
> > > >>       - patch series are split up to address ARM erratums first followed by TI
> > > >>         OMAP conversion
> > > >>       - More OMAP3 now get erratum implementation - had to redo rx51 a little
> > > >>       - I think is better helps exynos: https://patchwork.ozlabs.org/patch/443271/
> > > >>                       https://patchwork.ozlabs.org/patch/441863/
> > > >>       - Rearranged the series to address generic ARM first followed by rest.
> > > >>
> > > >> V2: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/213060
> > > >> V1: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/212174
> > > >>
> > > >> Nishanth Menon (10):
> > > >>   ARM: Introduce erratum workaround for 798870
> > > >>   ARM: Introduce erratum workaround for 454179
> > > >>   ARM: Introduce erratum workaround for 430973
> > > >>   ARM: Introduce erratum workaround for 621766
> > > >>   ARM: OMAP: Change set_pl310_ctrl_reg to be generic
> > > >>   ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs
> > > >>   ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with
> > > >>     omap_smc1
> > > >>   ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended
> > > >>     configuration
> > > >>   ARM: OMAP3: Enable workaround for ARM errata 454179, 430973, 621766
> > > >>   ARM: OMAP3: rx51: Enable workaround for ARM errata 454179, 430973,
> > > >>     621766
> > > >>
> > > >> Praveen Rao (1):
> > > >>   ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870
> > > >
> > > > Could you perhaps also pick up a workaround for "725233: PLD
> > > > instructions executed with PLD data forwarding enabled can result
> > > > in a processor deadlock" for old OMAP3 (r1pX revision of Cortex-A8)?
> > > >
> > > >     http://git.denx.de/?p=u-boot.git;a=commitdiff;h=041d42e789aba20296ffcde92173f100a9592880
> > > >
> > > > This used to be in U-Boot earlier, but seems to have vanished from the
> > > > current U-Boot code. I would probably submit a patch myself, but I
> > > > don't have such hardware anymore to test it.
> > > 
> > > Could I have a review by - I think I screwed up r1-r3 handling in
> > > start.S when multiple erratas are enabled - which by some luck, I
> > > have'nt hit.. I should probably fix that.
> > 
> > Sadly, I don't have this old hardware anymore. I have lent my first
> > generation beagleboard to another person several years ago and have no
> > idea where it is now. Maybe I should try to get it back one day :)
> > 
> > But taking the "formal" route, I checked who is the current beagleboard
> > maintainer and looks like that's Tom Rini, who is already quite
> > conveniently in the CC ;-)
> > 
> > Basically, this old hardware is either maintained or not. If it is
> > maintained, then probably the board maintainer is the best person to
> > review and test the errata patches.
> 
> Picking up again, I have original Beagleboards but I need a testcase.
> Is it as simple as "Linux still boots to login on serial and doesn't
> segfault everywhere" ?

In one way, this can be verified by just checking that the necessary
bits in the system registers are properly set according to the
recommendations from the errata lists. AFAIK, only writes to these
registers are restricted, so that it has to be done in an OMAP specific
way using the SMC calls. But reading them somewhere early in the
Linux kernel and doing printk should be fine. I hope that you have
access to your own copy of the Cortex-A8 errata list?

Regarding the testcases and the user visible impact. The IBE workaround
is needed for Thumb2 support. If it is not applied, then branch
prediction is broken and the CPU may end up in a wrong state (ARM vs.
Thumb2). You only need to have two large binaries (which do lots of
branching) running simultaneously, one compiled as ARM code and
another compiled as Thumb2. One of them will eventually die on a
context switch due to SIGILL or SIGSEGV.

One might need to be a little bit careful with the IBE workaround,
because there is a related problem "687067: BTB invalidate by MVA
operations will not work as intended when the IBE bit is enabled"
Which exists in all Cortex-A8 cores regardless of the revision.
However its impact is only limited to "invalidate by MVA operations",
and "invalidate all" operations are not affected. The Linux kernel
does not seem to ever use the "invalidate by MVA" operations. But
basically, if there is no real need to set the IBE bit, then it
should not be set on newer revisions of Cortex-A8 as suggested by
Paul Kocialkowski to avoid any theoretical troubles.

Regarding the L1NEON workaround. Unless it is applied to r1pX revisions
of Cortex-A8, most of the NEON code can't function and will deadlock
the processor. You can try ffmpeg, libjpeg-turbo, pixman or something
else to reproduce the problem. This one should be very easy to trigger.

Regarding the 725233 erratum ("PLD instructions executed with
PLD data forwarding enabled can result in a processor deadlock"),
it was much harder to reproduce. I believe that it might be triggered
even now by the pixman library test suite ("./configure && make check")
or one of the bundled pixman benchmark programs. But I would not rely
on that, because the pixman library has evolved since that time
and the exact conditions could have changed.

Thanks for picking this up.

-- 
Best regards,
Siarhei Siamashka