[U-Boot] U-boot broken on e500v2 soc

[York Sun]

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 at DTSEC1, FM1 at 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