[U-Boot] [PATCH 0/2] Unbreak OMAP3530

[U-Boot] [PATCH 0/2] Unbreak OMAP3530

[Siarhei Siamashka]

OMAP3530 lost the erratum 725233 workaround since 2011 and even
became completely non-bootable since 2015. These two patches make
it usable again. The most notable hardware is the original
BeagleBoard.

Siarhei Siamashka (2):
  arm: omap3: Compile clock.c with -marm option to unbreak OMAP3530
  arm: omap3: Bring back ARM errata workaround 725233

 arch/arm/cpu/armv7/start.S             | 13 +++++++++++++
 arch/arm/include/asm/arch-omap3/omap.h |  1 +
 arch/arm/mach-omap2/omap3/Makefile     |  3 +++
 arch/arm/mach-omap2/omap3/board.c      | 10 ++++++++++
 include/configs/ti_omap3_common.h      |  1 +
 scripts/config_whitelist.txt           |  1 +
 6 files changed, 29 insertions(+)

-- 
2.7.3

[U-Boot] [PATCH 1/2] arm: omap3: Compile clock.c with -marm option to unbreak OMAP3530

[Siarhei Siamashka]

Boards with OMAP3530 SoC fail to boot since commit bd2c4522c26d5
("ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)")
because it enabled the use of Thumb2 for the SPL.

Experiments have shown that the deadlock happens in the
prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c'.

This patch enforces the compilation of clock.c source file in
ARM mode and makes the deadlock disappear. We are yet to figure
out the root cause of the problem. Still this is somewhat
better than having non-bootable boards for years.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---
 arch/arm/mach-omap2/omap3/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/omap3/Makefile b/arch/arm/mach-omap2/omap3/Makefile
index b2fce96..06cc9f2 100644
--- a/arch/arm/mach-omap2/omap3/Makefile
+++ b/arch/arm/mach-omap2/omap3/Makefile
@@ -5,6 +5,9 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
+# If clock.c is compiled for Thumb2, then it fails on OMAP3530
+CFLAGS_clock.o += -marm
+
 obj-y	:= lowlevel_init.o
 
 obj-y	+= board.o
-- 
2.7.3

[U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233

[Siarhei Siamashka]

The workaround for ARM errata 725233 had been lost since
commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
maintenance framework). Bring it back in order to avoid
very difficult to reproduce, but actually encountered in
the wild CPU deadlocks when running software rendered
X11 desktop on OMAP3530 hardware.

This patch adds the new errata define to the whitelist instead
of introducing a new Kconfig option. It's probably best to
convert all ARM errata to Kconfig in one go via a separate
patch.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---
 arch/arm/cpu/armv7/start.S             | 13 +++++++++++++
 arch/arm/include/asm/arch-omap3/omap.h |  1 +
 arch/arm/mach-omap2/omap3/board.c      | 10 ++++++++++
 include/configs/ti_omap3_common.h      |  1 +
 scripts/config_whitelist.txt           |  1 +
 5 files changed, 26 insertions(+)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 7eee54b..1a6aee9 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -270,6 +270,19 @@ skip_errata_430973:
 skip_errata_621766:
 #endif
 
+#ifdef CONFIG_ARM_ERRATA_725233
+	cmp	r2, #0x21		@ Only on < r2p1 (Cortex A8)
+	bge	skip_errata_725233
+
+	mrc	p15, 1, r0, c9, c0, 2	@ Read L2ACR
+	orr	r0, r0, #(0x1 << 27)	@ L2 PLD data forwarding disable
+	push	{r1-r5}			@ Save the cpu info registers
+	bl	v7_arch_cp15_set_l2aux_ctrl
+	pop	{r1-r5}			@ Restore the cpu info - fall through
+
+skip_errata_725233:
+#endif
+
 	mov	pc, r5			@ back to my caller
 ENDPROC(cpu_init_cp15)
 
diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h
index 91d73c2..db763e4 100644
--- a/arch/arm/include/asm/arch-omap3/omap.h
+++ b/arch/arm/include/asm/arch-omap3/omap.h
@@ -243,6 +243,7 @@ struct gpio {
  * ROM code API related flags
  */
 #define OMAP3_GP_ROMCODE_API_L2_INVAL		1
+#define OMAP3_GP_ROMCODE_API_WRITE_L2ACR	2
 #define OMAP3_GP_ROMCODE_API_WRITE_ACR		3
 
 /*
diff --git a/arch/arm/mach-omap2/omap3/board.c b/arch/arm/mach-omap2/omap3/board.c
index 5f55977..cc83cd7 100644
--- a/arch/arm/mach-omap2/omap3/board.c
+++ b/arch/arm/mach-omap2/omap3/board.c
@@ -368,6 +368,16 @@ void __weak omap3_set_aux_cr_secure(u32 acr)
 			       (u32 *)&emu_romcode_params);
 }
 
+void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
+				 u32 cpu_rev_comb, u32 cpu_variant,
+				 u32 cpu_rev)
+{
+	if (get_device_type() == GP_DEVICE)
+		omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_L2ACR, l2auxctrl);
+
+	/* L2 Cache Auxiliary Control Register is not banked */
+}
+
 void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
 			  u32 cpu_variant, u32 cpu_rev)
 {
diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h
index 0ad3235..cbd6f98 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
@@ -25,6 +25,7 @@
 #define CONFIG_ARM_ERRATA_454179
 #define CONFIG_ARM_ERRATA_430973
 #define CONFIG_ARM_ERRATA_621766
+#define CONFIG_ARM_ERRATA_725233
 
 /* The chip has SDRC controller */
 #define CONFIG_SDRC
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index f6c9101..bb5387d 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -145,6 +145,7 @@ CONFIG_ARM_ERRATA_430973
 CONFIG_ARM_ERRATA_454179
 CONFIG_ARM_ERRATA_621766
 CONFIG_ARM_ERRATA_716044
+CONFIG_ARM_ERRATA_725233
 CONFIG_ARM_ERRATA_742230
 CONFIG_ARM_ERRATA_743622
 CONFIG_ARM_ERRATA_751472
-- 
2.7.3

[U-Boot] [PATCH 1/2] arm: omap3: Compile clock.c with -marm option to unbreak OMAP3530

[Tom Rini]

On Mon, Mar 06, 2017 at 03:16:52AM +0200, Siarhei Siamashka wrote:

> Boards with OMAP3530 SoC fail to boot since commit bd2c4522c26d5
> ("ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)")
> because it enabled the use of Thumb2 for the SPL.
> 
> Experiments have shown that the deadlock happens in the
> prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c'.
> 
> This patch enforces the compilation of clock.c source file in
> ARM mode and makes the deadlock disappear. We are yet to figure
> out the root cause of the problem. Still this is somewhat
> better than having non-bootable boards for years.
> 
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170306/0c48bc82/attachment.sig>

[U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233

[Tom Rini]

On Mon, Mar 06, 2017 at 03:16:53AM +0200, Siarhei Siamashka wrote:

> The workaround for ARM errata 725233 had been lost since
> commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
> maintenance framework). Bring it back in order to avoid
> very difficult to reproduce, but actually encountered in
> the wild CPU deadlocks when running software rendered
> X11 desktop on OMAP3530 hardware.
> 
> This patch adds the new errata define to the whitelist instead
> of introducing a new Kconfig option. It's probably best to
> convert all ARM errata to Kconfig in one go via a separate
> patch.
> 
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

In concept:
Reviewed-by: Tom Rini <trini@konsulko.com>

Do you want to v2 on top of my patch that migrates the current ARM
errata or would you rather I v2 it and apply?  Thanks again!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170308/0c2e9dc7/attachment.sig>

[U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233

[Siarhei Siamashka]

On Wed, 8 Mar 2017 09:30:07 -0500
Tom Rini <trini@konsulko.com> wrote:

> On Mon, Mar 06, 2017 at 03:16:53AM +0200, Siarhei Siamashka wrote:
> 
> > The workaround for ARM errata 725233 had been lost since
> > commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
> > maintenance framework). Bring it back in order to avoid
> > very difficult to reproduce, but actually encountered in
> > the wild CPU deadlocks when running software rendered
> > X11 desktop on OMAP3530 hardware.
> > 
> > This patch adds the new errata define to the whitelist instead
> > of introducing a new Kconfig option. It's probably best to
> > convert all ARM errata to Kconfig in one go via a separate
> > patch.
> > 
> > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>  
> 
> In concept:
> Reviewed-by: Tom Rini <trini@konsulko.com>

Thanks!
 
> Do you want to v2 on top of my patch that migrates the current ARM
> errata or would you rather I v2 it and apply?  Thanks again!
 
Sure, either way is fine for me.

There is just one thing that is not very good yet. Setting the
L2 Auxiliary Control Register is currently a no-op in my patch
for the HS variants of OMAP3430/3530 because they are using a
different secure monitor API. And I don't know anything
about it and don't even have such hardware to run any tests.

And there is not much that can be done about it there. We have
no serial console yet to print any diagnostic warnings.

So I wonder if it makes sense to add one more errata related
patch, responsible for verifying correctness of the applied
errata workarounds at a much later stage. Basically, the difference
is the following. When applying errata workarounds:
  * Writing to coprocessor registers is restricted and may
    require the use of SoC-specific secure monitor API.
  * Errata workarounds need to be applied as early as possible
    and we don't have the serial console for any debugging
    or diagnostic messages yet.
And when validating errata workarounds:
  * Reading coprocessor registers is not a problem and can be
    done via a simple MRC instruction.
  * The validation can be done at any time, even postponed
    until just before loading the OS kernel. We can print
    warnings if something is not right or even abort booting
    (after printing a comprehensive error message).

So if I implement such additional errata validation patch, then
anyone with a HS OMAP3430 device can notice that there is a
problem and implement the missing L2 Auxiliary Control Register
setup code. What do you think about this?

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233

[Tom Rini]

On Fri, Mar 10, 2017 at 05:55:37PM +0200, Siarhei Siamashka wrote:
> On Wed, 8 Mar 2017 09:30:07 -0500
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Mon, Mar 06, 2017 at 03:16:53AM +0200, Siarhei Siamashka wrote:
> > 
> > > The workaround for ARM errata 725233 had been lost since
> > > commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
> > > maintenance framework). Bring it back in order to avoid
> > > very difficult to reproduce, but actually encountered in
> > > the wild CPU deadlocks when running software rendered
> > > X11 desktop on OMAP3530 hardware.
> > > 
> > > This patch adds the new errata define to the whitelist instead
> > > of introducing a new Kconfig option. It's probably best to
> > > convert all ARM errata to Kconfig in one go via a separate
> > > patch.
> > > 
> > > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>  
> > 
> > In concept:
> > Reviewed-by: Tom Rini <trini@konsulko.com>
> 
> Thanks!
>  
> > Do you want to v2 on top of my patch that migrates the current ARM
> > errata or would you rather I v2 it and apply?  Thanks again!
>  
> Sure, either way is fine for me.

OK.  I'm building the conversion now.

> There is just one thing that is not very good yet. Setting the
> L2 Auxiliary Control Register is currently a no-op in my patch
> for the HS variants of OMAP3430/3530 because they are using a
> different secure monitor API. And I don't know anything
> about it and don't even have such hardware to run any tests.
> 
> And there is not much that can be done about it there. We have
> no serial console yet to print any diagnostic warnings.
> 
> So I wonder if it makes sense to add one more errata related
> patch, responsible for verifying correctness of the applied
> errata workarounds at a much later stage. Basically, the difference
> is the following. When applying errata workarounds:
>   * Writing to coprocessor registers is restricted and may
>     require the use of SoC-specific secure monitor API.
>   * Errata workarounds need to be applied as early as possible
>     and we don't have the serial console for any debugging
>     or diagnostic messages yet.
> And when validating errata workarounds:
>   * Reading coprocessor registers is not a problem and can be
>     done via a simple MRC instruction.
>   * The validation can be done at any time, even postponed
>     until just before loading the OS kernel. We can print
>     warnings if something is not right or even abort booting
>     (after printing a comprehensive error message).
> 
> So if I implement such additional errata validation patch, then
> anyone with a HS OMAP3430 device can notice that there is a
> problem and implement the missing L2 Auxiliary Control Register
> setup code. What do you think about this?

Adding an optional verification stage (or command) could be interesting.
I don't see a problem in concept with adding something, again so long as
it's optional.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170310/89a09c13/attachment.sig>