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 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.