From: fabrice.gasnier@st.com (Fabrice Gasnier)
To: linux-arm-kernel@lists.infradead.org
Subject: Why are imprecise external aborts masked on recent kernel while booting ?
Date: Mon, 3 Feb 2014 17:43:22 +0100 [thread overview]
Message-ID: <52EFC72A.6060608@st.com> (raw)
In-Reply-To: <52EF5D8E.4050600@st.com>
Hi,
I had no success with msr instruction to set CPSR.A bit.
I re-checked on a 3.4 kernel, msr instruction present in former
"kernel_thread_helper()" routine was not responsible for clearing CPSR.A
bit.
'A' bit was cleared because SPSR was altered before executing following
instruction in arch/arm/kernel/entry-header.S :
movs pc, lr @ return & move spsr_svc into cpsr
Sorry for the confusion in my first email: that movs instruction was
responsible for clearing 'A' bit on 3.4 kernel. But on recent kernel,
"restore_user_regs" macro seems no longer called for a kernel thread.
So, I tried the 'cps'instruction that does it! I re-worked slightly your
previous patch.
I also noticed that secondary needs to be set separately.
Please, could you comment on the following patch ? (I can resend
correctly formated patch if you wish) :
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index dc894ab..e22b109 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -378,6 +378,9 @@ asmlinkage void secondary_start_kernel(void)
local_irq_enable();
local_fiq_enable();
+ /* Enable imprecise aborts */
+ asm volatile("cpsie a");
+
/*
* OK, it's off to the idle thread for us
*/
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 4636d56..a9567bb 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
+
+ /* Enable imprecise aborts */
+ asm volatile("cpsie a");
+
#else /* ifndef CONFIG_CPU_V7M */
/*
* on V7-M there is no need to copy the vector table to a dedicated
Thanks,
BR,
Fabrice
On 02/03/2014 10:12 AM, Fabrice Gasnier wrote:
> Hi Russell,
>
> Thank you for your help.
> I just tried following patch on both 3.10 and above vanilla 3.13.1.
> Unfortunately, these instructions have no effect on the arm cpsr.
> I dumped regs right after msr instruction have been executed. It
> remains untouched :
>
> Here is assembly from gdb:
>
> 0xc064a400 <+128>: mov r3, #256 ; 0x100
> 0xc064a404 <+132>: mrs r2, CPSR
> 0xc064a408 <+136>: bic r2, r2, r3
> 0xc064a40c <+140>: msr CPSR_c, r2
>
> CPSR.A bit is still set after these instructions : 0x600001d3
> Although, I see it has been cleared in r2: 0x600000d3
>
> Please advise.
> Thanks,
> BR,
> Fabrice
> On 01/31/2014 06:08 PM, Russell King - ARM Linux wrote:
>>> Is it possible to unmask imprecise data aborts earlier in the boot
>>> >process (e.g. before PCIe bus enumeration, when drivers are being
>>> probed)
>>> >?
>> How about this patch?
>>
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 172ee18ff124..b0ff06f49cd0 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -900,6 +900,15 @@ void __init early_trap_init(void *vectors_base)
>> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
>> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
>> +
>> + /* Enable imprecise aborts */
>> + asm volatile(
>> + "mrs %0, cpsr\n"
>> + " bic %0, %0, %1\n"
>> + " msr cpsr_c, %0"
>> + : "=&r" (i)
>> + : "r" (PSR_A_BIT));
>> +
>> #else /* ifndef CONFIG_CPU_V7M */
>> /*
>> * on V7-M there is no need to copy the vector table to a
>> dedicated
>
next prev parent reply other threads:[~2014-02-03 16:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 15:59 Why are imprecise external aborts masked on recent kernel while booting ? Fabrice Gasnier
2014-01-31 17:08 ` Russell King - ARM Linux
2014-02-03 9:12 ` Fabrice Gasnier
2014-02-03 16:43 ` Fabrice Gasnier [this message]
2014-02-07 16:20 ` Fabrice Gasnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52EFC72A.6060608@st.com \
--to=fabrice.gasnier@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.