[PATCH 00/10] ARM: V7M: Support caches
Vladimir Murzin
vladimir.murzin at arm.com
Wed Jun 15 05:43:32 PDT 2016
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 at 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
>
>
>
>
More information about the linux-arm-kernel
mailing list