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
>
>
>
>
prev parent 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).