From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Erickson Date: Tue, 29 Apr 2008 13:39:44 -0700 Subject: [U-Boot-Users] Using Data Cache for the Primordial Stack on the 405EX[r] (was Re: [PATCH v2] PPC405EX(r) ECC and SDRAM Initialization Clean-ups) In-Reply-To: <200804291142.53005.sr@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 4/29/08 2:42 AM, Stefan Roese wrote: > On Tuesday 29 April 2008, kenneth johansson wrote: >>>> Stefan already asked this... I would also like to understand why the >>>> data cache cannot be used for initial RAM as we do on so many other >>>> systems? >>> >>> Agreed. The changes were based on the comments in the Kilauea and Makalu >>> board ports indicating that this had been attempted--twice--and didn't >>> work. >>> >>> I am escalating with AMCC to find out if this is a processor errata, >>> board issue or just a programming issue that needs to be investigated >>> further. >> >> The cache trick works fine on 405CR/405GP. Is the cache redesigned for >> 405EX. Why would they still call it a 405 if the core was redesigned? > > I already sent an update to Grant privately on this. Here again: > > The main problem is that the board crashes with an exception (0x200: Data > machine check) when init RAM in dcache is used. This happens upon calling > trap_init() in board_init_r(). The exception must be pending and > is "activated" upon the trap_init() call. Either Grant (or somebody else?) > will look into this, or I will try to look into is (again) in a few days. > > Thanks. > > Best regards, > Stefan For those following this thread, here are the result of my investigations today: When using the Haleakala board and configuring include/configs/kilauea.h as follows: #define CFG_SDRAM_BASE 0x00000000 #define CFG_INIT_DCACHE_CS 3 #define CFG_INIT_RAM_ADDR (CFG_SDRAM_BASE + (1 << 30)) I find the following results while tracking the various exception-related registers: 1) At _start + 0: MSR : 0x0000 0000 ESR (0x3D4) : 0x0000 0000 DEAR (0x3D5) : 0x0000 0000 SRR0 (0x01A) : 0x0000 0700 SRR1 (0x01B) : 0x0000 0000 SRR2 (0x3DE) : 0xFFFA 8678 (NfsStart + 0x2c) SRR3 (0x3DF) : 0x0000 0000 MCSR (0x23C) : 0x0000 0000 MCAR (0x23D) : 0x0000 0000 MCSRR0 (0x23A): 0x0000 0000 MCSRR1 (0x23B): 0x0000 0000 EBC0_BEAR : 0x0000 0000 EBC0_BESR : 0x0000 0000 2) After both invalidate_icache() and invalidate_dcache() have run: 3) After a NOP ext_bus_cntlr_init() has run: 4) After PBxAP and PBxCR have been set-up for the desired EBC region: 5) After the data cacheability has been set for this range: MSR : 0x0000 0000 ESR (0x3D4) : 0x0000 0000 DEAR (0x3D5) : 0x0000 0000 SRR0 (0x01A) : 0x0000 0700 SRR1 (0x01B) : 0x0000 0000 SRR2 (0x3DE) : 0xFFFA 8678 (NfsStart + 0x2c) SRR3 (0x3DF) : 0x0000 0000 MCSR (0x23C) : 0x0000 0000 MCAR (0x23D) : 0x0000 0000 MCSRR0 (0x23A): 0x0000 0000 MCSRR1 (0x23B): 0x0000 0000 EBC0_BEAR : 0x0000 0000 * EBC0_BESR : 0x4000 0000 PERR=1 5) Immediately after the following instruction runs: lis r1,CFG_INIT_RAM_ADDR at h MSR : 0x0000 0000 ESR (0x3D4) : 0x0000 0000 DEAR (0x3D5) : 0x0000 0000 SRR0 (0x01A) : 0x0000 0700 SRR1 (0x01B) : 0x0000 0000 SRR2 (0x3DE) : 0xFFFA 8678 (NfsStart + 0x2c) SRR3 (0x3DF) : 0x0000 0000 * MCSR (0x23C) : 0xA000 0000 MCS = 1, DPLBE = 1 MCAR (0x23D) : 0x0000 0000 MCSRR0 (0x23A): 0x0000 0000 MCSRR1 (0x23B): 0x0000 0000 EBC0_BEAR : 0x0000 0000 EBC0_BESR : 0x4000 0000 PERR=1 However, the overall operation does appear to be working in terms of priming the primordial stack with known values: (gdb) info registers r2 r2 0x40000fc4 (gdb) print /x *$r2 $1 = 0xdeaddead (gdb) x /64xw 0x40000FC0 0x40000fc0: 0x00000000 0xdeaddead 0xdeaddead 0xdeaddead 0x40000fd0: 0xdeaddead 0xdeaddead 0xdeaddead 0xdeaddead 0x40000fe0: 0xdeaddead 0xdeaddead 0xdeaddead 0xdeaddead 0x40000ff0: 0xdeaddead 0xdeaddead 0xdeaddead 0xdeaddead 0x40001000: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001010: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001020: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001030: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001040: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001050: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001060: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001070: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001080: 0x00000000 0x00000000 0x00000000 0x00000000 0x40001090: 0x00000000 0x00000000 0x00000000 0x00000000 0x400010a0: 0x00000000 0x00000000 0x00000000 0x00000000 0x400010b0: 0x00000000 0x00000000 0x00000000 0x00000000 Other Experiments Tried: Changing: #define CFG_INIT_DCACHE_CS 3 to 4, 5, 6, or 7 doesn't seem to make any difference except I then also seem to get BOTH IPLBE=1 and DPLBE=1 in MCSR for 4, 5, 6 or 7. While this seems to work OK on older 405 variants, is there something new or different about the PLB to OPB to EBC bridges in the 405EX[r] relative to those older 405 variants that cause this CFG_INIT_DCACHE_CS primordial stack trick to raise an exception where the others before it did not? Regards, Grant