linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vladimir.murzin@arm.com (Vladimir Murzin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/10] ARM: V7M: Support caches
Date: Wed, 15 Jun 2016 13:43:32 +0100	[thread overview]
Message-ID: <57614D74.1040308@arm.com> (raw)
In-Reply-To: <57612A90.5030808@st.com>

On 15/06/16 11:14, Alexandre Torgue wrote:
> Hi Vladimir,
> 
> On 06/13/2016 06:29 PM, Alexandre Torgue wrote:
>> Hi Vladimir,
>>
>> On 06/13/2016 06:19 PM, Vladimir Murzin wrote:
>>> Hi Alex,
>>>
>>> On 13/06/16 17:09, Alexandre Torgue wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 06/13/2016 05:02 PM, Vladimir Murzin wrote:
>>>>> Hi,
>>>>>
>>>>> This patch set allows M-class cpus benefit of optional cache support.
>>>>> It originaly was written by Jonny, I've been keeping it localy mainly
>>>>> rebasing over Linux versions.
>>>>>
>>>>> The main idea behind patches is to reuse existing cache handling code
>>>>> from v7A/R. In case v7M cache operations are provided via memory
>>>>> mapped interface rather than co-processor instructions, so extra
>>>>> macros have been introduced to factor out cache handling logic and
>>>>> low-level operations.
>>>>>
>>>>> Along with the v7M cache support the first user (Cortex-M7) is
>>>>> introduced.
>>>>>
>>>>> Patches were tested on MPS2 platform with Cortex-M3/M4/M7. The later
>>>>> one showed significant boot speed-up.
>>>>>
>>>>> Based on 4.7-rc3.
>>>>>
>>>>> Thanks!
>>>>> Vladimir
>>>>>
>>>>
>>>> Thanks for the series.
>>>> Did you change something in those patches compare to patches you
>>>> sent in
>>>> the RFC ?
>>>
>>> Only 04, 05, 06 have been changed (each has it's own changelog
>>> included).
>>>
>>> I did try to hammer patches because of your report of instability with
>>> caches on, but all run fine... so nothing has been changed in regard of
>>> your case.
>>>
>> Ok. Thanks for this input. From now, I will use this series to perform
>> my tests. I will continue to debug my instabilities this week.
>> I will let you know.
>>
> I fixed my instabilities and it was linked to my SDRAM timings :(.
> I don't see behavior issues with your series (You can add my Tested-by:
> Alexandre TORGUE <alexandre.torgue@st.com>).
> 

Great! Since I have to re-work series per Russell comments I'd very
appreciate your Tested-by on further versions of the patch set.

> I have two others questions for you:
> 
> 1- Maybe I didn't search deeper in the code but when you enable Dcache
> and Icache, what is the state of cache ? I mean we need to invalidate
> caches before enable it. It is done by kernel (with your patches) or it
> has to be done by a bootloader ?
> 

I believe it follows A/R practice, so, yes, it is up to the bootloader
to make sure that cache state is consistent.

> 2- I observe an issue (IMO not linked to your series) when I switch
> off/switch on my board. During the first boot after an hard reset I get
> a bus error  (BFSR part in CFSR register indicates an "A bus fault on an
> instruction prefetch has occurred."). After SRST reset through JTAG, the
> kernel boot correctly.
> Do you already seen this kind of issue ?
> 

I didn't see anything like that, sorry.

Thanks
Vladimir

> I add the backtrace and registers info.
> 
> __invalid_entry () at arch/arm/kernel/entry-v7m.S:33
> 33    1:    b    1b
> (gdb) bt
> #0  __invalid_entry () at arch/arm/kernel/entry-v7m.S:33
> #1  0xc000bc2a in unwind_exec_insn (ctrl=<optimized out>) at
> arch/arm/kernel/unwind.c:321
> #2  unwind_frame (frame=0xc023d0c0 <reset_devices>) at
> arch/arm/kernel/unwind.c:449
> #3  0xc000caec in ?? () at arch/arm/mm/cache-v7.S:69
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) f 3
> #3  0xc000caec in ?? () at arch/arm/mm/cache-v7.S:69
> 69           ret     lr
> (gdb) info reg
> r0             0x1    1
> r1             0x0    0
> r2             0x1    1
> r3             0x0    0
> r4             0x0    0
> r5             0x100    256
> r6             0x0    0
> r7             0xa    10
> r8             0x40096    262294
> r9             0x0    0
> r10            0xc012b004    -1072517116
> r11            0x0    0
> r12            0x29    41
> sp             0xc0230018    0xc0230018 <cpu_cache+4>
> lr             0xc000caed    -1073689875
> pc             0xc000caec    0xc000caec <v7_flush_icache_all>
> xPSR           0x81000005    -2130706427
> 
> 
> Thanks for your time.
> 
> Alex
> 
> 
> 
> 

      reply	other threads:[~2016-06-15 12:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 15:02 [PATCH 00/10] ARM: V7M: Support caches Vladimir Murzin
2016-06-13 15:03 ` [PATCH 01/10] ARM: factor out CSSELR/CCSIDR operations that use cp15 directly Vladimir Murzin
2016-06-13 15:03 ` [PATCH 02/10] ARM: V7M: Make read_cpuid() generally available on V7M Vladimir Murzin
2016-06-13 15:15   ` Russell King - ARM Linux
2016-06-13 16:21     ` Vladimir Murzin
2016-06-13 15:03 ` [PATCH 03/10] ARM: V7M: Add addresses for mem-mapped V7M cache operations Vladimir Murzin
2016-06-13 15:03 ` [PATCH 04/10] ARM: V7M: Add support for reading the CTR with CPUID_CACHETYPE Vladimir Murzin
2016-06-13 15:03 ` [PATCH 05/10] ARM: Extract cp15 operations from cache flush code Vladimir Murzin
2016-06-13 15:03 ` [PATCH 06/10] ARM: V7M: Implement cache macros for V7M Vladimir Murzin
2016-06-13 15:18   ` Russell King - ARM Linux
2016-06-13 16:27     ` Vladimir Murzin
2016-06-13 16:29       ` Russell King - ARM Linux
2016-06-13 16:34         ` Vladimir Murzin
2016-06-13 15:03 ` [PATCH 07/10] ARM: V7M: fix notrace variant of save_and_disable_irqs Vladimir Murzin
2016-06-13 15:03 ` [PATCH 08/10] ARM: V7M: Wire up caches for V7M processors with cache support Vladimir Murzin
2016-06-13 15:03 ` [PATCH 09/10] ARM: V7M: Indirect proc_info construction for V7M CPUs Vladimir Murzin
2016-06-13 15:03 ` [PATCH 10/10] ARM: V7M: Add support for the Cortex-M7 processor Vladimir Murzin
2016-06-13 16:09 ` [PATCH 00/10] ARM: V7M: Support caches Alexandre Torgue
2016-06-13 16:19   ` Vladimir Murzin
2016-06-13 16:29     ` Alexandre Torgue
2016-06-15 10:14       ` Alexandre Torgue
2016-06-15 12:43         ` Vladimir Murzin [this message]

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=57614D74.1040308@arm.com \
    --to=vladimir.murzin@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).