arm: ls1021a: Ensure Generic Timer disabled before jumping into the OS
PATCH 1/1 arm: ls1021a: Ensure Generic Timer disabled before jumping into the OS
This patch addresses a problem mentioned recently on this mailing list:
[1].
In that posting a LS1021 based system was locking up at about 5 minutes after boot,but the problem was mysteriously related to the toolchain used for building u-boot.Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM generic PL1 physical time CompareValue register to all-ones with a 32-bit value.This causes the timer compare to fire 344 seconds after u-boot configures it.Depending on how fast u-boot gets the kernel booted,this amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by default compiler options, word sizes, or binutils versions.
To fix the above issue, the generic physical timer is disabled before jumping to the OS.
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/014400.html
--- arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/arm/cpu/armv7/ls102xa/cpu.c +10 -0
@@ -346,3 +346,13 @@ void smp_kick_all_cpus(void) out_be32(&gur->brrl, 0x2); }#endif + +void arch_preboot_os (void ) +{ +unsigned long ctrl; + +/* Disable PL1 Physical Timer */ + asm("mrc p15, 0, %0, c14, c2, 1" :"=r" (ctrl)); + ctrl &= ~ARCH_TIMER_CTRL_ENABLE ; + asm("mcr p15, 0, %0, c14, c2, 1" : :"r" (ctrl)); +}
Signature · 1 line
2.1.0.27.g96db324
PATCH 1/1 arm: ls1021a: Ensure Generic Timer disabled before jumping into the OS
Quoted 39 lines · Alison Wang
This patch addresses a problem mentioned recently on this mailing list:
[1].In that posting a LS1021 based system was locking up at about 5 minutes after boot,but the problem was mysteriously related to the toolchain used for building u-boot.Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM generic PL1 physical time CompareValue register to all-ones with a 32-bit value.This causes the timer compare to fire 344 seconds after u-boot configures it.Depending on how fast u-boot gets the kernel booted,this amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by default compiler options, word sizes, or binutils versions.
To fix the above issue, the generic physical timer is disabled before jumping to the OS.
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/014400.htmlSigned-off-by Chris Kilgour <[email protected]>Signed-off-by Alison Wang <[email protected]>--- arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/cpu/armv7/ls102xa/cpu.c +0
-0@@ -346,3 +346,13 @@ void smp_kick_all_cpus(void) out_be32(&gur->brrl, 0x2); }#endif
arch/arm/cpu/armv7/ls102xa/cpu.c void smp_kick_all_cpus(void) · line 358
Quoted 10 lines
arch/arm/cpu/armv7/ls102xa/cpu.c +10
-0+ +void arch_preboot_os (void ) +{ +unsigned long ctrl; + +/* Disable PL1 Physical Timer */ + asm("mrc p15, 0, %0, c14, c2, 1" :"=r" (ctrl)); + ctrl &= ~ARCH_TIMER_CTRL_ENABLE ; + asm("mcr p15, 0, %0, c14, c2, 1" : :"r" (ctrl)); +}
Mark,
Can you comment on this patch? I believe this is the follow-up after discussion here http://patchwork.ozlabs.org/patch/495476/.
York
Hello Alison,
Quoted 38 lines · Alison Wang
This patch addresses a problem mentioned recently on this mailing list:
[1].In that posting a LS1021 based system was locking up at about 5 minutes after boot,but the problem was mysteriously related to the toolchain used for building u-boot.Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM generic PL1 physical time CompareValue register to all-ones with a 32-bit value.This causes the timer compare to fire 344 seconds after u-boot configures it.Depending on how fast u-boot gets the kernel booted,this amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by default compiler options, word sizes, or binutils versions.
To fix the above issue, the generic physical timer is disabled before jumping to the OS.
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/014400.htmlSigned-off-by Chris Kilgour <[email protected]>Signed-off-by Alison Wang <[email protected]>--- arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/cpu/armv7/ls102xa/cpu.c +0
-0@@ -346,3 +346,13 @@ void smp_kick_all_cpus(void) out_be32(&gur->brrl, 0x2); }#endif
arch/arm/cpu/armv7/ls102xa/cpu.c void smp_kick_all_cpus(void) · line 358
Quoted 10 lines
arch/arm/cpu/armv7/ls102xa/cpu.c +10
-0+ +void arch_preboot_os (void ) +{ +unsigned long ctrl; + +/* Disable PL1 Physical Timer */ + asm("mrc p15, 0, %0, c14, c2, 1" :"=r" (ctrl)); + ctrl &= ~ARCH_TIMER_CTRL_ENABLE ; + asm("mcr p15, 0, %0, c14, c2, 1" : :"r" (ctrl)); +}
This only disables the timer when booting linux. Does the possibly misconfigured timer compare value (only lower 32-bits are set to 0xffffffff) have any side-effects within u-boot? I don't currently know the timer is used there. I would prefer that the inline assembly code in timer_init is fixed to pass an 64-bit variable to mcrr. Maybe someone will take that code snippet as an example and such problems occur again. Opinions?
Best regards,
Alexander
Signature · 17 lines
Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.stein at systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax: +49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
Hi, Alexander,
Quoted 55 lines · Alison Wang
Quoted 1 line
This patch addresses a problem mentioned recently on this mailing
list:
Quoted 9 lines
[1].
In that posting a LS1021 based system was locking up at about 5 minutes after boot,but the problem was mysteriously related to the toolchain used for building u-boot.Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM generic PL1 physical time CompareValue register to all-
ones
Quoted 7 lines
with a 32-bit value.This causes the timer compare to fire 344 seconds after u-boot configures it.Depending on how fast u-boot gets the kernel booted,this amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by default compiler options, word sizes, or binutils
versions.
Quoted 6 lines
To fix the above issue, the generic physical timer is disabled before jumping to the OS.
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/0144
Quoted 16 lines
00.html
Signed-off-by Chris Kilgour <[email protected]>Signed-off-by Alison Wang <[email protected]>--- arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/cpu/armv7/ls102xa/cpu.c +0
-0@@ -346,3 +346,13 @@ void smp_kick_all_cpus(void)out_be32 (&gur->brrl,0x2 ); }arch/arm/cpu/armv7/ls102xa/cpu.c void smp_kick_all_cpus(void) · line 357
Quoted 10 lines
arch/arm/cpu/armv7/ls102xa/cpu.c +9
-0#endif + +void arch_preboot_os (void ) +{ +unsigned long ctrl; + +/* Disable PL1 Physical Timer */ + asm("mrc p15, 0, %0, c14, c2, 1" :"=r" (ctrl)); + ctrl &= ~ARCH_TIMER_CTRL_ENABLE ; + asm("mcr p15, 0, %0, c14, c2, 1" : :"r" (ctrl)); }
Quoted 8 lines
This only disables the timer when booting linux. Does the possibly misconfigured timer compare value (only lower 32-bits are set to
0xffffffff) have any side-effects within u-boot? I don't currently know the timer is used there.
I would prefer that the inline assembly code intimer_initis fixed to pass an 64-bit variable to mcrr. Maybe someone will take that code snippet as an example and such problems occur again. Opinions?
[Alison Wang] Thanks for your reply. I agree with you that the misconfigured Timer compare value should be fixed too. So except this patch, the patch on
http://patchwork.ozlabs.org/patch/495476/ need to be applied too.
Best Regards,
Alison Wang
Hi, Mark and Alexander,
Do you have any comment about this patch?
Thanks.
Best Regards,
Alison Wang
Quoted 72 lines
Quoted 55 lines · Alison Wang
Quoted 1 line
This patch addresses a problem mentioned recently on this mailing
list:
Quoted 9 lines
[1].
In that posting a LS1021 based system was locking up at about 5 minutes after boot,but the problem was mysteriously related to the toolchain used for building u-boot.Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM generic PL1 physical time CompareValue register to all-
ones
Quoted 7 lines
with a 32-bit value.This causes the timer compare to fire 344 seconds after u-boot configures it.Depending on how fast u-boot gets the kernel booted,this amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by default compiler options, word sizes, or binutils
versions.
Quoted 6 lines
To fix the above issue, the generic physical timer is disabled before jumping to the OS.
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/0144
Quoted 16 lines
00.html
Signed-off-by Chris Kilgour <[email protected]>Signed-off-by Alison Wang <[email protected]>--- arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/cpu/armv7/ls102xa/cpu.c +0
-0@@ -346,3 +346,13 @@ void smp_kick_all_cpus(void)out_be32 (&gur->brrl,0x2 ); }arch/arm/cpu/armv7/ls102xa/cpu.c void smp_kick_all_cpus(void) · line 357
Quoted 10 lines
arch/arm/cpu/armv7/ls102xa/cpu.c +9
-0#endif + +void arch_preboot_os (void ) +{ +unsigned long ctrl; + +/* Disable PL1 Physical Timer */ + asm("mrc p15, 0, %0, c14, c2, 1" :"=r" (ctrl)); + ctrl &= ~ARCH_TIMER_CTRL_ENABLE ; + asm("mcr p15, 0, %0, c14, c2, 1" : :"r" (ctrl)); }Quoted 8 lines
This only disables the timer when booting linux. Does the possibly misconfigured timer compare value (only lower 32-bits are set to
0xffffffff) have any side-effects within u-boot? I don't currently know the timer is used there.
I would prefer that the inline assembly code intimer_initis fixed to pass an 64-bit variable to mcrr. Maybe someone will take that code snippet as an example and such problems occur again. Opinions?[Alison Wang] Thanks for your reply. I agree with you that the misconfigured Timer compare value should be fixed too. So except this patch, the patch on http://patchwork.ozlabs.org/patch/495476/ need to be applied too.
Best Regards,
Alison Wang
Hi,
Quoted 70 lines · Huan Wang
Do you have any comment about this patch?
Thanks.Quoted 68 lines
Quoted 55 lines · Alison Wang
Quoted 1 line
This patch addresses a problem mentioned recently on this mailing
list:
Quoted 9 lines
[1].
In that posting a LS1021 based system was locking up at about 5 minutes after boot,but the problem was mysteriously related to the toolchain used for building u-boot.Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM generic PL1 physical time CompareValue register to all-
ones
Quoted 7 lines
with a 32-bit value.This causes the timer compare to fire 344 seconds after u-boot configures it.Depending on how fast u-boot gets the kernel booted,this amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by default compiler options, word sizes, or binutils
versions.
Quoted 6 lines
To fix the above issue, the generic physical timer is disabled before jumping to the OS.
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/0144
Quoted 16 lines
00.html
Signed-off-by Chris Kilgour <[email protected]>Signed-off-by Alison Wang <[email protected]>--- arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)arch/arm/cpu/armv7/ls102xa/cpu.c +0
-0@@ -346,3 +346,13 @@ void smp_kick_all_cpus(void)out_be32 (&gur->brrl,0x2 ); }arch/arm/cpu/armv7/ls102xa/cpu.c void smp_kick_all_cpus(void) · line 357
Quoted 10 lines
arch/arm/cpu/armv7/ls102xa/cpu.c +9
-0#endif + +void arch_preboot_os (void ) +{ +unsigned long ctrl; + +/* Disable PL1 Physical Timer */ + asm("mrc p15, 0, %0, c14, c2, 1" :"=r" (ctrl)); + ctrl &= ~ARCH_TIMER_CTRL_ENABLE ; + asm("mcr p15, 0, %0, c14, c2, 1" : :"r" (ctrl)); }Quoted 8 lines
This only disables the timer when booting linux. Does the possibly misconfigured timer compare value (only lower 32-bits are set to
0xffffffff) have any side-effects within u-boot? I don't currently know the timer is used there.
I would prefer that the inline assembly code intimer_initis fixed to pass an 64-bit variable to mcrr. Maybe someone will take that code snippet as an example and such problems occur again. Opinions?[Alison Wang] Thanks for your reply. I agree with you that the misconfigured Timer compare value should be fixed too. So except this patch, the patch on http://patchwork.ozlabs.org/patch/495476/ need to be applied too.
Same opinion here. Both patches should be applied.
Best regards,
Alexander
Signature · 17 lines
Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.stein at systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax: +49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
Mark Rutland
Acked-byQuoted 4 lines · Huan Wang
Hi, Mark and Alexander,
Do you have any comment about this patch?
Thanks.
The patch looks good to me. FWIW:
Mark.
York Sun
AppliedPATCH 1/1 arm: ls1021a: Ensure Generic Timer disabled before jumping into the OS
In reply to Alison WangQuoted 21 lines · Alison Wang
This patch addresses a problem mentioned recently on this mailing list:
[1].In that posting a LS1021 based system was locking up at about 5 minutes after boot,but the problem was mysteriously related to the toolchain used for building u-boot.Debugging the problem reveals a stuck interrupt 29 on the GIC.
It appears Freescale's LS1021 support in u-boot erroneously sets the 64-bit ARM generic PL1 physical time CompareValue register to all-ones with a 32-bit value.This causes the timer compare to fire 344 seconds after u-boot configures it.Depending on how fast u-boot gets the kernel booted,this amounts to about 5-minutes of Linux uptime before locking up.
Apparently the bug is masked by some toolchains. Perhaps this is explained by default compiler options, word sizes, or binutils versions.
To fix the above issue, the generic physical timer is disabled before jumping to the OS.
Quoted 6 lines
[1]
https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/014400.htmlSigned-off-by Chris Kilgour <[email protected]>Signed-off-by Alison Wang <[email protected]>---
Applied to fsl-qoriq master. Thanks.
York