[#4917] KGDB single step into the middle of a 4 bytes instruction on bf561 after soft bp is hit.
Submitted By: Sonic Zhang
2009-02-19 00:00:29 Close Date
Closed Fixed In Release:
Found In Release:
BF561 Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
Toolchain version or rev.:
SVN trunk 4.1
App binary format:
Summary: KGDB single step into the middle of a 4 bytes instruction on bf561 after soft bp is hit.
KGDB single step into the middle of a 4-byte instruction on bf561 after soft bp is hit at this 4-byte instruction. No problem with hardware bp.
The configuration is default with KGDB and KGDB_TESTS enabled.
# CONFIG_NO_HZ is not set
Wrong output after hit software bp:
L1(before change) : data variable addr = 0xff800000, data value is 0
L1 : code function addr = 0xffa003dc
L1(after change) : data variable addr = 0xff800000, data value is 10
L2(before change) : data variable addr = 0xfeb00084, data value is 0
L2 : code function addr = 0xfeb00000
L2(after change) : data variable addr = 0xfeb00084, data value is 20
L1(before change) : data variable addr = 0xff800000, data value is 10
L1(after change) : data variable addr = 0xff800000, data value is 20
L2(before change) : data variable addr = 0xfeb00084, data value is 20
L2(after change) : data variable addr = 0xfeb00084, data value is 40
Correct output without software bp:
--- Sonic Zhang 2009-02-23 04:22:58
If turn off ICACHE, this bug disappear.
--- Sonic Zhang 2009-02-23 05:38:04
This bug is confirmed to be an issue in the icache invalidate code. If following
sequence is met, the wrong instruction is loaded.
1) The one instruction address is cached in the icache.
2) This instruction in SDRAM is changed.
3) IFLASH[P0] is executed only once in blackfin_icache_flush_range().
4) This instruction is executed then.
This issue is walked around properly till Mike clean up the cache flush code in
r5419 | vapier | 2008-10-15 03:05:48 +0800 (Wed, 15 Oct 2008) | 1 line
unify/cleanup cache code to (1) be correct wrt to end ranges and (2) be optimal
with a one-instruction hardware loop
Should add the walkarround back.
--- Sonic Zhang 2009-02-23 05:52:26
--- Mike Frysinger 2009-02-23 11:23:39
this doesnt make sense. either the icache gets flushed, or it doesnt.
executing iflush twice on the same address should make no difference at all.
you've changed the code so it does:
start = start & -L1_CACHE_BYTES;
so even if start is in the middle of a cache line (which it rarely is), the
IFLUSH should still hit the same cache line.
--- Bernd Schmidt 2009-02-23 11:38:46
Were there any other workarounds in that file that were lost in r5419?
--- Mike Frysinger 2009-02-23 11:49:22
this isnt a documented issue. this is "it seems to work" but there's
no real information.
other csync/ssync's were dropped, but those all applied to old Blackfins we do
--- Robin Getz 2009-02-23 12:21:12
Yeah, I not sure I follow how this is a fix.
--- Sonic Zhang 2009-02-23 23:16:40
IFLUSH twice is the only walkaround found lost in r5419.
This is a walkaround to fix this bug. I don't find a documented anomaly yet.
Yes, the 2 IFLUSH hit the same cache line. The bug occurs if this cache line is
flushed only once. Any idea on the real root cause?
--- Mike Frysinger 2009-02-23 23:27:51
can you describe exactly what's going on so we can be reproduced w/out linux let
--- Sonic Zhang 2009-02-23 23:49:36
You can reproduce it in following steps:
0) config DCACHE in WT mode and enable ICACHE.
1) In following kegb_test() function, replace the first 2 bytes of the 4-byte
instruction at address 0x8866 with 2-byte instruction 0xa1.
2) call kgdb_test() for first time
3) exception is hit
4) in trap.c replace 2-byte instruction 0xa1 with the backup 2 bytes.
5) invalidate the instruction from addr to addr + 2, IFLUSH only once.
5) minus PC by 2 on saved register stack and return from the exception.
6) First instruction loaded after return is the 2-byte instruction 0xa1, not
the original 4-byte instruction.
Dump of assembler code for function kgdb_test:
0x0000885c <kgdb_test+0>: LINK 0x14; /* (20) */
0x00008860 <kgdb_test+4>: [FP + 0x8] = R0;
0x00008862 <kgdb_test+6>: [FP + 0xc] = R1;
0x00008864 <kgdb_test+8>: [FP + 0x10] = R2;
0x00008866 <kgdb_test+10>: R1.H = 0x10; /* ( 16)
R1=0x0x100000 <unix_dgram_poll+56>(1048576) */
0x0000886a <kgdb_test+14>: R1.L = 0x688c; /* (26764)
0x0000886e <kgdb_test+18>: R2 = [FP + 0xc];
0x00008870 <kgdb_test+20>: R0 = [FP + 0x10];
0x00008872 <kgdb_test+22>: [SP + 0xc] = R0;
0x00008874 <kgdb_test+24>: R0 = [FP + 0x14];
0x00008876 <kgdb_test+26>: [SP + 0x10] = R0;
0x00008878 <kgdb_test+28>: R0 = R1;
0x0000887a <kgdb_test+30>: R1 = R2;
0x0000887c <kgdb_test+32>: R2 = [FP + 0x8];
0x0000887e <kgdb_test+34>: P2.H = 0x1; /* ( 1)
P2=0x0x10000 <do_fork+476> */
0x00008882 <kgdb_test+38>: P2.L = 0xcd8; /* (3288)
P2=0x0x10cd8 <printk> */
0x00008886 <kgdb_test+42>: CALL (P2);
0x00008888 <kgdb_test+44>: R0 = [FP + 0x14];
0x0000888a <kgdb_test+46>: [FP + 0x10] = R0;
0x0000888c <kgdb_test+48>: R0 = [FP + 0x10];
0x0000888e <kgdb_test+50>: UNLINK;
0x00008892 <kgdb_test+54>: RTS;
--- Mike Frysinger 2009-02-23 23:53:00
thanks, i think that's enough for me to try and reproduce with like u-boot/jtag
--- Sonic Zhang 2009-02-23 23:59:58
Correct one line.
6) First instruction loaded after return is a 2-byte instruction, may not be
0xa1, but also not the original 4-byte instruction.
--- Robin Getz 2009-02-24 07:07:28
I know there were some undocumented issues about 32-bit or 64-bit instructions
getting replaced by a 16-bit breakpoints, and having the remaining
"tail" opcodes being decoded in the pipeline, and causing issues like
But I don't think a flush would fix that. Would be interesting to understand if
a CSYNC also fixed things.
--- Sonic Zhang 2009-02-25 00:41:21
Both CSYNC and SSYNC don't help.
--- Mike Frysinger 2009-02-27 02:12:19
does this only occur on the bf561-ezkit ? or have you checked other boards ?
--- Sonic Zhang 2009-02-27 03:06:04
No. This was initially discovered on BF533-STAMP and BF537-STAMP.
--- Mike Frysinger 2009-02-27 16:55:00
so how exactly is this test working on the board ? the original summary has a
dearth of information ...
to try to reproduce, i took a BF537-EZKIT with 0.3 silicon and:
$ make AnalogDevices/BF537-STAMP_default
$ make linux_menuconfig
<enable CONFIG_KGDB and CONFIG_KGDB_TESTS>
then i booted the kernel and ran:
root:/> cat /proc/kgdbtest
L1 : code function addr = 0xffa00390
then i ran the same `cat` command over and over and every time i would get the
same three lines of output
presumably something else needs to be happening here ... what is that ?
--- Mike Frysinger 2009-02-28 14:35:42
ok, i read through the kgdb expect script and found out how to reproduce this
my tests though indicate this is a problem with kgdb_disable_hw_debug(). if i
remove the writes of 0 to WPIACTL and WPDCTL, things seem to work.
this might also explain why when i connect with gdb over jtag things work one
time and then crash: gdb over jtag set the PWR bit in those registers and then
kgdb cleared them. so writing 0 to the PWR bit when it's already 0 looks like
it causes misbehavior.
i'll check with design
File Name File Type File Size Posted By
No Files Were Found