[U-Boot-Users] 85xx running in RAM problems

[U-Boot-Users] 85xx running in RAM problems

[robert lazarski]

Hi all,

On my custom 8548 board I'm getting two different results - with a BDI
[INIT] config, and without. With the BDI [INIT] config, I can get
farther by setting the DDR2 ram size to be 256MB instead of what I
have, 1GB. I have no other SDRAM besides DDR2. Sorry for the long
post. I can set in the BDI the following:

 ;# CS0_BNDS
;# bit 8-15 - starting address
;# bit 24-31 - ending address, configured for 256MB
WM32    0xE0002000 0x0000000f ; DDR CS0

;# CS0_CONFIG
WM32    0xE0002080 0x80000102

;# TIMING_CFG_0
WM32    0xE0002104 0x00260802

;# TIMING_CFG_1
WM32    0xE0002108 0x38355322

And by doing so, I can get U-boot running in ram:

U-Boot 1.3.0-rc1-g67c31036-dirty (Oct 18 2007 - 11:43:18)

CPU:   8548_E, Version: 2.0, (0x80390020)
Core:  E500, Version: 2.0, (0x80210020)
Clock Configuration:
       CPU: 888 MHz, CCB: 355 MHz,
       DDR: 177 MHz, LBC:  22 MHz
L1:    D-cache 32 kB enabled
       I-cache 32 kB enabled
Board: MPC8548ATUM
I2C:   ready
DRAM:  Initializing
spd_sdram
 cs0 already configured, bnds=f
       Reusing current 256MB configuration
DDR: MAS0=0x10080000
DDR: MAS1=0xc0000900
DDR: MAS2=0x00000000
DDR: MAS3=0x00000015
DDR: LAWBAR1=0x00000000
DDR: LARAR1=0x80f0001b
    DDR: 256 MB
Top of RAM usable for U-Boot at: 10000000
Reserving 207k for U-Boot at: 0ffc0000
Reserving 136k for malloc() at: 0ff9e000
Reserving 80 Bytes for Board Info at: 0ff9dfb0
Reserving 48 Bytes for Global Data at: 0ff9df80
Stack Pointer at: 0ff9df68
New Stack Pointer is: 0ff9df68
Now running in RAM - U-Boot at: 0ffc0000
FLASH: flash detect cfi
fwc addr f8000000 cmd 0 0 8bit x 8 bit
fwc addr f8000055 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr f8000010 is= ff 51
fwc addr f8000555 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr f8000010 is= ff 51
fwc addr f8000000 cmd 0 0000 16bit x 8 bit
fwc addr f80000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr f8000020 is= 0051 5151
fwc addr f8000aaa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr f8000020 is= 0051 5151
fwc addr f8000000 cmd 0 0000 16bit x 16 bit
fwc addr f80000aa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr f8000020 is= 0051 0051
is= cmd 52(R) addr f8000022 is= 0052 0052
is= cmd 59(Y) addr f8000024 is= 0059 0059
ushort addr is at f8000050 info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x2
addr[2] = 0x0
addr[3] = 0x0
retval = 0x2
device interface is 2
found port 2 chip 2 port 16 bits chip 16 bits
ushort addr is at f8000026 info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x2
addr[2] = 0x0
addr[3] = 0x0
retval = 0x2
fwc addr f8000000 cmd f0 00f0 16bit x 16 bit
fwc addr f8000aaa cmd aa 00aa 16bit x 16 bit
fwc addr f8000554 cmd 55 0055 16bit x 16 bit
fwc addr f8000aaa cmd 90 0090 16bit x 16 bit
fwc addr f8000000 cmd f0 00f0 16bit x 16 bit
fwc addr f80000aa cmd 98 0098 16bit x 16 bit
ushort addr is at f800002a info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x40
addr[2] = 0x0
addr[3] = 0x0
retval = 0x40
f8000020 : 00 51 00 52 00 59 00 02 00 00 00 40 00 00 00 00  .Q.R.Y..... at ....
f8000030 : 00 00 00 00 00 00 00 27 00 36 00 00 00 00 00 06  .......'.6......
f8000040 : 00 06 00 09 00 13 00 03 00 05 00 03 00 02 00 1b  ................
f8000050 : 00 02 00 00 00 06 00 00 00 01 00 ff 00 03 00 00  ................
f8000060 : 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
f8000070 : 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff  ................
f8000080 : 00 50 00 52 00 49 00 31 00 33 00 14 00 02 00 01  .P.R.I.1.3......
f8000090 : 00 00 00 08 00 00 00 00 00 02 00 b5 00 c5 00 05  ................
manufacturer is 2
manufacturer id is 0x1
device id is 0x7e
device id2 is 0x2801
cfi version is 0x3133
size_ratio 1 port 16 bits chip 16 bits
found 1 erase regions
long addr is at f800005a info->portwidth = 2
addr[0] = 0x0
addr[1] = 0xff
addr[2] = 0x0
addr[3] = 0x3
addr[4] = 0x0
addr[5] = 0x0
addr[6] = 0x0
addr[7] = 0x2
erase_region_count = 1024 erase_region_size = 131072
ushort addr is at f8000054 info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x6
addr[2] = 0x0
addr[3] = 0x0
retval = 0x6
fwc addr f8000000 cmd f0 00f0 16bit x 16 bit
flash_protect ON: from 0xFFF80000 to 0xFFFAD4FF
protect on 1020
protect on 1021
flash_protect ON: from 0xFFFC0000 to 0xFFFFFFFF
protect on 1022
protect on 1023
128 MB
L2 cache 512KB: already enabled.
*** Warning - bad CRC, using default environment

   pci_init_board: devdisr=700c0001, io_sel=6, host_agent=7
    PCIE1: disabled

    PCI1: 32 bit, 33 MHz, sync, host, arbiter (base address e0008000)
               Scanning PCI bus 00
PCI1 on bus 00 - 00
    PCI2: disabled
In:    serial
Out:   serial
Err:   serial
U-Boot relocated to 0ffc0000
iivpr1 at e005

Where it hangs after setting IVPR - another problem I'll tackle after
my DDR2 issues. Note the above "cs0 already configured, bnds=f" from
spd_sdram() . If I set bnds=3f (1GB) via the BDI - or run with any BDI
INIT and just rely on spd_sdram() , it hangs here:

Stack Pointer at: 3ff9df68
New Stack Pointer is: 3ff9df68

The only place I'm setting up DDR2 besides calling spd_sdram() is here:

.long  (LAWAR_TRGT_DDR | (LAWAR_SIZE & LAWAR_SIZE_1G)) & ~LAWAR_EN

And here:

#define CFG_DDR_SDRAM_BASE      0x00000000      /* DDR is system memory*/

Any ideas?
Robert

[U-Boot-Users] 85xx running in RAM problems

[David Hawkins]

Hi Robert,

> On my custom 8548 board I'm getting two different results - with a BDI
> [INIT] config, and without. With the BDI [INIT] config, I can get
> farther by setting the DDR2 ram size to be 256MB instead of what I
> have, 1GB. I have no other SDRAM besides DDR2. 

Have you run any sort of memory tests from the BDI prompt?
For example, lets assume your BDI init file setups up
the DDR2 correctly, but there is a short on the board.

If you run some from of memory checks using the BDI
memory read/write commands, you should be able to detect
the short.

Common tests are walking 1's or 0's over the data bus,
and then clearing RAM and writing to one location, and
testing the result can't be read from more than one
location.

I'm not sure whether the BDI has these sorts of functions
built in, but there are people who've use Tcl/Expect to
layer on the BDI to build a test suite.

Unless you can guarantee your RAM is working fine, there's
no point in trying to get code to run.

The other option is writing a very small program you can load
using the BDI - not a stand-along U-Boot program, just
a stand-alone program that takes over from reset.

Hope that helps,
Dave

[U-Boot-Users] 85xx running in RAM problems

[robert lazarski]

On 10/18/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
> Hi Robert,
>
> > On my custom 8548 board I'm getting two different results - with a BDI
> > [INIT] config, and without. With the BDI [INIT] config, I can get
> > farther by setting the DDR2 ram size to be 256MB instead of what I
> > have, 1GB. I have no other SDRAM besides DDR2.
>
> Unless you can guarantee your RAM is working fine, there's
> no point in trying to get code to run.
>

I figured this out - we got the different behavior via BDI [INIT] from
the TIMING_CFG_n params leftover from CDS. The values detected from
SPD weren't working at all on the first batch of memory chips we
tried. In fact, we moved to higher quality Kingston DDR2 and SPD
started working and we got the u-boot prompt! I nearly hit the ceiling
;-) . I ran mtest in u-boot and after running all day, it passed.

Thanks all,
Robert

[U-Boot-Users] 85xx running in RAM problems

[David Hawkins]

robert lazarski wrote:
> On 10/18/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
>> Hi Robert,
>>
>>> On my custom 8548 board I'm getting two different results - with a BDI
>>> [INIT] config, and without. With the BDI [INIT] config, I can get
>>> farther by setting the DDR2 ram size to be 256MB instead of what I
>>> have, 1GB. I have no other SDRAM besides DDR2.
>>
>> Unless you can guarantee your RAM is working fine, there's
>> no point in trying to get code to run.
>>
> 
> I figured this out - we got the different behavior via BDI [INIT] from
> the TIMING_CFG_n params leftover from CDS. The values detected from
> SPD weren't working at all on the first batch of memory chips we
> tried. In fact, we moved to higher quality Kingston DDR2 and SPD
> started working and we got the u-boot prompt! I nearly hit the ceiling
> ;-) . I ran mtest in u-boot and after running all day, it passed.
> 

Glad to hear it!
Cheers,
Dave