public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] U-boot broken on e500v2 soc
Date: Mon, 23 Nov 2015 17:19:27 -0600	[thread overview]
Message-ID: <1448320767.27264.266.camel@freescale.com> (raw)
In-Reply-To: <56501037.3080300@freescale.com>

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 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?

-Scott

  parent reply	other threads:[~2015-11-23 23:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-21  6:33 [U-Boot] U-boot broken on e500v2 soc York Sun
2015-11-23 11:49 ` Valentin Longchamp
2015-11-23 23:19 ` Scott Wood [this message]
2015-12-01 18:39   ` York Sun
2015-12-02  0:36     ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1448320767.27264.266.camel@freescale.com \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox