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:
<same>
3) After a NOP ext_bus_cntlr_init() has run:
<same>
4) After PBxAP and PBxCR have been set-up for the desired EBC region:
<same>
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@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