[U-Boot-Users] 85xx running in RAM problems
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.....@.... 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@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
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
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
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
participants (2)
-
David Hawkins -
robert lazarski