[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)

[Grant Erickson]

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