On 11/23/2015 03:19 PM, Scott Wood wrote: > 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.
If comment out the invalidate_cache_range(), this problem goes away. I can see several calls of this function in e1000 driver. Shall we keep this function only for CONFIG_4xx and CONFIG_MPC86xx? That's what we had before. > >> 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? > It is not a valid instruction. The reloacaddr is 0x1FEF0000. Doing the math, the original instruction would be at 0xF0016F10 which is beyond the image. I think this is caused by wrongly invalidated data. York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
