[U-Boot] [PATCH 0/2] Unbreak OMAP3530
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(+)
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
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
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
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!
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?
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.
participants (2)
-
Siarhei Siamashka -
Tom Rini