Hi.
On Mon, Jun 29, 2020 at 12:29 AM Masahiro Yamada <masahi...@kernel.org> wrote:
>
> On Wed, Jun 24, 2020 at 11:07 AM Volodymyr Babchuk
> <volodymyr_babc...@epam.com> wrote:
> >
> > ARM Architecture reference manual clearly states that PE pipeline
> > should be flushed after any change to system registers. Refer to
> > paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture
> > Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI
> > 0487B.a).
> >
> > Failing to issue instruction memory synchronization barrier can lead
> > to spurious errors, like synchronous exception when accessing FPU
> > registers. This is very prominent on CPUs with long instruction
> > pipeline, like ARM Cortex A72.
> >
> > This change fixes the following U-Boot panic:
> >
> > "Synchronous Abort" handler, esr 0x1fe00000
> > elr: 00000000800948cc lr : 0000000080091e04
> > x0 : 00000000801ffdc8 x1 : 00000000000000c8
> > x2 : 00000000800979d4 x3 : 00000000801ffc60
> > x4 : 00000000801ffd40 x5 : ffffff80ffffffd8
> > x6 : 00000000801ffd70 x7 : 00000000801ffd70
> > x8 : 000000000000000a x9 : 0000000000000000
> > x10: 0000000000000044 x11: 0000000000000000
> > x12: 0000000000000000 x13: 0000000000000000
> > x14: 0000000000000000 x15: 0000000000000000
> > x16: 000000008008b2e0 x17: 0000000000000000
> > x18: 00000000801ffec0 x19: 00000000800957b0
> > x20: 00000000000000c8 x21: 00000000801ffdc8
> > x22: 000000008009909e x23: 0000000000000000
> > x24: 0000000000000000 x25: 0000000000000000
> > x26: 0000000000000000 x27: 0000000000000000
> > x28: 0000000000000000 x29: 00000000801ffc50
> >
> > Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0)
> >
> > While executing instruction
> >
> > str q0, [sp, #112]
> >
> > in vsnprintf() prologue. This panic was observed only on Cortex A72 so
> > far.
> >
> > This patch places ISBs on other strategic places as well.
> >
> > Also, this probably is the right fix for the issue workarounded in the
> > commit 45f41c13 ("ARM: uniphier: add weird workaround code for LD20")
>
>
> Thanks for addressing this issue.
> Currently, I do not have a board in hand to test this.
> (I do not commute to the office due to COVID-19 these days...)
>
> I have another SoC board, but it does not integrate CA72.
> I have ever seen this problem only on CA72.
>
> Eventually, I will go to the office, and I can test this.
> But, you do not need to wait for my test if other people
> review it.
>
> Thank you.
>
Today I tested this patch.
Yes, it fixes the CA72 problem on my board.
Tested-by: Masahiro Yamada <yamada.masah...@socionext.com>
After this patch is picked up,
I will revert the ugly workaround:
http://patchwork.ozlabs.org/project/uboot/patch/20200706042304.15853-1-yamada.masah...@socionext.com/
Interestingly, I observe this problem
only on U-Boot running at EL1.
Anyway, this fix makes it work at
any exception level.
--
Best Regards
Masahiro Yamada
