On Fri, 2015-11-20 at 22:33 -0800, York Sun wrote: > Valentin, > > Can you refresh my memory why you needed this > commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch > http://patchwork.ozlabs.org/patch/455439)? > Today I bisect an issue back to this commit. > > Scott, > > Can you help to examine this u-boot commit? Before this commit, > 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and > flush_dcache_range(). With this patch, I found e500v2 is broken on Intel > e1000 > card when testing v2016-rc1. I didn't catch this issue when testing this > patch. > > I wonder if this code is not safe for e500v2, or because the cache line size > should be determined by reading L1CFG0. Why didn't we see any issue with > Linux > with the same code.
L1_CACHE_SIZE should be 5 as long as CONFIG_E500MC is not defined. I'm not sure what Linux has to do with this since it isn't the same code (in particular, Linux knows that the I/O is coherent and doesn't flush on e500). What happens if you comment out invalidate_cache_range() but leave flush_cache_range()? We should never need to do the former on e500. > Log for testing on e500v2 > > P1023RDB > > U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:01:56 -0800) > > CPU0: P1023E, Version: 1.1, (0x80fe0011) > Core: e500, Version: 5.1, (0x80212151) > Clock Configuration: > CPU0:500 MHz, CPU1:500 MHz, > CCB:333.333 MHz, > DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz > FMAN1: 333.333 MHz > QMAN: 0 MHz > L1: D-cache 32 KiB enabled > I-cache 32 KiB enabled > Board: P1023 RDB > I2C: ready > DRAM: DIMM 0: is not a DDR3 SPD. > SPD error on controller 0! Trying fallback to raw timing calculation > Detected UDIMM Fixed DDR on board > 512 MiB (DDR3, 32-bit, CL=5, ECC off) > Flash: 64 MiB > L2: 256 KiB enabled > NAND: 128 MiB > EEPROM: CRC mismatch (a7fdad5b != ffffffff) > PCIe1: Root Complex of Slot 1, no link, regs @ 0xff60a000 > PCIe1: Bus 00 - 00 > PCIe2: Root Complex of Slot 2, x1 gen1, regs @ 0xff609000 > 02:00.0 - 8086:107d - Network controller > PCIe2: Bus 01 - 02 > PCIe3: Root Complex of Slot 3, x1 gen1, regs @ 0xff60b000 > 04:00.0 - 168c:0030 - Network controller > PCIe3: Bus 03 - 04 > In: serial > Out: serial > Err: serial > Net: Fman1: Uploading microcode version 160.0.18 > e1000: 00:15:17:8e:7b:8d > FM1@DTSEC1, FM1@DTSEC2, e1000#0 [PRIME] > Warning: e1000#0 MAC addresses don't match: > Address in SROM is 00:15:17:8e:7b:8d > Address in environment is 00:e0:0c:00:06:02 > > => ping $serverip > Using e1000#0 device > Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00 > NIP: 1FFC6F10 XER: 00000000 LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: > 20000000 > MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > > GPR00: 1FF457D4 1F8EDB60 1F8EDF14 20000000 00020000 0000001F 00000000 1F8EDAB8 > GPR08: A0003818 00004000 00000003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24 > GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068 00000000 1FFC6F10 > GPR24: 1FFB00CC 1FF48D60 00000000 1F8F3D70 1FFC5600 00400000 1FF5C610 00400000 > Call backtrace: > 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90 > 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454 > 1FEF0F4C > Exception in kernel pc 1ffc6f10 signal 0 > ### ERROR ### Please RESET the board ### 0xe00 is an instruction TLB error. Could you dump the TLB when this happens? DAR of 0x20000000 looks like something that would actually cause a problem, but that's only relevant to data exceptions, not instruction. What is the instruction at 0x1ffc6f10? -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
