On Fri, Feb 15, 2013 at 02:37:49PM +0000, Dietmar Eggemann wrote:
> dropped linux-arm-ker...@lists.infradead.org
> <linux-arm-ker...@lists.infradead.org>
>
> On 15/02/13 12:06, Jon Medhurst (Tixy) wrote:
> > On Fri, 2013-02-15 at 10:33 +0000, Lorenzo Pieralisi wrote:
> >> On Fri, Feb 15, 2013 at 10:04:37AM +0000, Jon Medhurst (Tixy) wrote:
> >>> On Thu, 2013-02-14 at 17:16 +0000, Will Deacon wrote:
> >>>> Hi Tixy,
> >>>>
> >>>> On Thu, Feb 14, 2013 at 05:07:43PM +0000, Jon Medhurst (Tixy) wrote:
> >>>>> The function v7_coherent_kern_range uses the macro icache_line_size to
> >>>>> read the current CPUs icache line size for the purpose of invalidating
> >>>>> all cache lines in the given range.
> >>>>>
> >>>>> Unfortunately, on the TC2 big.LITTLE test chip, the A15 icache line size
> >>>>> is 64 bytes, but the A7 size is only 32 bytes. So when the function
> >>>>> executes on the A15 it will miss out every alternate cache line for the
> >>>>> A7.
> >>>>
> >>>> There is a signal (IMINLN) to the core which allows A15 to behave as
> >>>> though
> >>>> it has a 32-byte line size and this should be driven correctly for
> >>>> big/little.
> >>>
> >>> How do we set that signal? Is that something we have to set up in Linux
> >>> or is it something that we expect the Firmware to set up?
> >>
> >> If I am not mistaken, SCC register at offset 0x400 (bit 7) allows IMINLN to
> >> be forced to 0 (ie Instruction Cache minimum line size == 32 bytes).
> >>
> >> This can be done through board.txt so that it is set up as we want.
> >
> > According to the TRM for TC2 the default value for that register is
> > 0x33330c80, so adding the line "SCC: 0x400 0x33330c00" and incrementing
> > TOTALSCCS does the trick, and the A15's now report an icache size of 32.
> >
> > We'll have to get everyone with a TC2 to make that change then?
>
> Hi,
>
> I tried with SCC: 0x400 0x33330c00 and incremented TOTALSCCS but it
> makes no difference for me.
>
> With cpuidle state1 enabled on all CPUs, the system stops after
>
> root@linaro-nano:/sys/kernel/debug/tracing# echo function > current_tracer
>
> When I attach the debugger I can always see that one A15 stopped here:
>
> #0 atomic_add_return( v = <Value not available : Failed to read 4 bytes
> from address S:0x0000001D because Bus error on memory operation.>, i = 1
> ) at atomic.h:62
> #1 function_trace_call( ip = 3221328812, parent_ip = 3221331569, op =
> <Value currently has no location>, pt_regs = <Value currently has no
> location> ) at trace_functions.c:109
> #2 [S:0x00001008]
>
> i r
> R0 0xC0084E89 3221769865
> R1 0x00000001 1
> R2 0x00000001 1
> R3 0xEF0C4000 4010557440
> R4 0xC1BCDE88 3250380424
> R5 0x200001D3 536871379
> R6 0xC05FB3AC 3227497388
> R7 0xC0019E71 3221331569
> R8 0xC00193AC 3221328812
> R9 0xC0B54EF8 3233107704
> R10 0x00000000 0
> R11 0x00000000 0
> R12 0x00000000 0
> SP 0xEF0C5E78 0xEF0C5E78
> LR 0xC0084E89 0xC0084E89 <current_thread_info+0x1>
> PC 0xC0084E9E 0xC0084E9E <atomic_add_return+0x4>
> CPSR 0x200001F3 nzCvq_ge3ge2ge1ge0_inactive_eAIFTj_SVC
>
> disas 0xC0084E9A
> S:0xC0084E9A : DMB
> S:0xC0084E9E : LDREX r2,[r4] <--- PC
> S:0xC0084EA2 : ADD r2,r2,#1
> S:0xC0084EA6 : STREX r1,r2,[r4]
> S:0xC0084EAA : TEQ r1,#0
> S:0xC0084EAE : BNE {pc}-0x10 ; 0xc0084e9e
> S:0xC0084EB0 : DMB
>
> CP15_SCTLR: 0x50C53879
> ...
> C ... disable
Looks like code relying on ldrex/strex is being run with C bit cleared
which is a recipe for disasters.
We should avoid tracing power down functions, I have to compile and
disassemble the kernel to be more precise, just guessing.
Lorenzo
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
