Hi everyone,
I have a custom MPC8540-based board running U-boot 1.1.4. The processor core runs at 833MHz and the memory is DDR 333MHz with ECC. With a single banked SoDIMM memory module, 256 or 512Mbyte, the board can run a memory test and boot/run linux 2.6.15. With a multiple banked (2) 1Gbyte memory module, the board can boot/run linux 2.6.15, but, the memory test hangs in the vicinity of the bank (512Mbyte) boundary. The uboot fill command also hangs. We can also generate a hang condition by doing a sequence of reads of a memory range that crosses the bank boundary. Individual peeks and pokes of memory work fine. It seems that a prolonged sequence of accesses is required to cause the problem.
If I run 'mtest 1fff0000 20010000' (over the 512MB boundary on a 1GB module), the test hangs in seconds.
If I use a 512MB SoDIMM module which use two Chip Selects (2 banks). I can run 'mtest fff0000 10010000' from U-boot for hours without a problem.
Investigation with a JTAG emulator shows that the processor is not hung, but rather the code is stuck in a loop trying to output characters to the serial port (polling the LSR in the DUART for the transmitter to be empty). According to the JTAG emulator, the data being read in the loop during the "hang" condition was 0. However, if I read the register manually using the emulator, the value returned is 0x60 which should have caused the loop to exit and the character to be written.
On the board, we have an LED register connected to the local bus. If I write to the LEDs prior to the DUART LSR polling loop the memory test runs fine. What effect should the local bus access have on the DUART polling loop? According to the code and the emulator, the DUART registers do not show up in the data cache.
Since we are testing over a nearly 1Gbyte memory range (the exception table and the u-boot area are excluded), and the code only writes to the serial port before and after the memory fill operation and then before and after the read/verify operation, I cannot see that the led register write is having any significant impact on the DRAM access timing.
The following is the DRAM initialization data from Uboot:
DRAM: Initializing DDR: number of banks = 2 DDR: DDR I bank density = 0x20000000 Number of Row Address Bits - 13 Number of Col Address Bits - 11
DDR: cs0_bnds = 0x0000001f DDR: cs0_config = 0x80000103 DDR: cs1_bnds = 0x0020003f DDR: cs1_config = 0x80000103 DDR: caslat SPD bit is 3 DDR: tCKmin = 6000 ps DDR: Module max data rate = 333 Mhz DDR: effective data rate is 333 MHz DDR: caslat SPD bit is 3, controller field is 0x4 DDR: ext_refrec = 0x00000000 DDR: timing_cfg_1 = 0x37344321 DDR: timing_cfg_2 = 0x00000c00 DDR: sdram_mode = 0x00000062 DDR: sdram_mode_2 = 0x00000000 DDR: sdram_interval = 0x05130100 DDR: err_disable = 0x0000000d DDR: err_sbe = 0x00ff0000 DDR: sdram_cfg_2 = 0x00000000 ECC enabled DDR: sdram_cfg = 0xe2008000 Setup for 256MB pagesize Setup TLB index #8 for address 0x00000000 DDR: MAS0=0x10080000 DDR: MAS1=0xc0000900 DDR: MAS2=0x00000000 DDR: MAS3=0x00000015 Setup TLB index #9 for address 0x10000000 DDR: MAS0=0x10090000 DDR: MAS1=0xc0000900 DDR: MAS2=0x10000000 DDR: MAS3=0x10000015 Setup TLB index #10 for address 0x20000000 DDR: MAS0=0x100a0000 DDR: MAS1=0xc0000900 DDR: MAS2=0x20000000 DDR: MAS3=0x20000015 Setup TLB index #11 for address 0x30000000 DDR: MAS0=0x100b0000 DDR: MAS1=0xc0000900 DDR: MAS2=0x30000000 DDR: MAS3=0x30000015 DDR: LAWBAR1=0x00000000 DDR: LARAR1=0x80f0001d DMA DDR: err_disable = 0x0000000d DMA DDR: err_disable = 0x00000000 DDR: 1024 MB
This is the uboot serial routine with the led writes:
void NS16550_putc (NS16550_t com_port, char c) { /* snc - debug */ volatile unsigned char *led = (volatile unsigned char *)0xffb00000;
*led = 0xa; while ((com_port->lsr & LSR_THRE) == 0); com_port->thr = c; }
I am pretty sure that the memory design is OK since even with a 2 bank, 1GB memory module will, the board will boot and run linux, mount its root filesystem over NFS, be able to mount an NFS partition containing the linux 2.6.15 kernel source, and be able to repeatedly compile the kernel over NFS overnight.
Anyone have any thoughts?
Thanks in advance,
Scott
___________________________________________________________________
Scott N. Coulter Senior Software Engineer
Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com U.S.A. Web: http://www.cyclone.com ___________________________________________________________________