OMAP-L138: 256MB DDR memory problem

Daniel Carlson

Part Number: OMAP-L138

Hi Team,

I have a customer who is using the OMAP-L138 and is trying to get it working with 256MB DDR memory. They are experiencing some issues with this. Comments from customer are below:

"I thought it was be a simple matter of changing a few parameters in u-boot,

but not so. The version of u-boot we’re using is a bit old (2012.04.01).

Both memories work for 128MB.

This old version of u-boot does not seem to have any configuration of the SDCR and

DDR related registers. The latest/greatest version of u-boot has more going on (da850_lowlevel.c).

Moving to the new u-boot has it’s own issues, so I’m trying to get the old version working first.

I am determining that the full 256 MB isn’t available by:

1. write a pattern to 0xC000_0030

2. read back to verify

3. read from 0xC800_0030, seeing pattern written to 0xC000_0000 -> larger memory not working

I do have the memory length set to

#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */

#define PHYS_SDRAM_1_SIZE (256 << 20) /* SDRAM size 256MB */

Old memory 128MB:

Micron MT46H64M16LF

New memory 256MB, same footprint:

Micron MT46H128M16LF"

Can you give some help on this?

Thanks,

Daniel

over 5 years ago

0 Brad Griffis over 5 years ago

TI__Guru*** 125430 points

The first thing I would compare is the number of rows, banks and column bits for each of the memories. I suspect that the newer larger part needs an extra row bit. The number of row bits is configured in the SDCR2 register in its ROWSIZE field.

0 Daniel Carlson over 5 years ago in reply to Brad Griffis

TI__Prodigy 370 points

Hi Brad,

Here is the response from my customer. Have any suggestions?:

"I dumped the registers listed in the bottom table from the uboot that runs

with both the 128 and 256MB chips.

I noticed the row address line count in SDCR2 was 0. Changing it to 5 had no impact

Changing SDCR PAGESIZE (using either u-boot md or in u-boot board_init()) to 3 caused u-boot to crash.

Architecture	64 Meg x 16
Configuration	32 Meg x 16 x 4 banks
Refresh Count	8k
Row Addressing	16K A[13:0]
Column Addressing	2K A11, A[9:0]

Register	Address	Page	Current Value	New Value	Notes
REVID	0xB000 0000	419	40311B1F
SDRSTAT	0xB000 0004	420	40000004
SDCR	0xB000 0008	421	0A034622	0A034623	Writing 0x23 to 0xB0000008 crashes u-boot
SDRCR	0xB000 000C	424	00000494
SDTIMR1	0xB000 0010	425	1C912A08
SDTIMR2	0xB000 0014	426	3811C700
SDCR2	0xB000 001C	427	00000000	00000005	No impact
PBBPR	0xB000 0020	428	000000FF
PC1	0xB000 0040	429	0086E883
PC2	0xB000 0044	429	001E7DB0
PCC	0xB000 0048	430	00010000
PCMRS	0xB000 004C	432	00000000
PCT	0xB000 0050	433	0830834A
DRPYRcR	0xB000 0060	433	00002091
IRR	0xB000 00C0	434	00000000
IMR	0xB000 00C4	434	00000000
IMSR	0xB000 00C8	435	00000000
IMCR	0xB000 00CC	436	00000000
DRPYC1R	0xB000 00E4	437	000000C4
VTPIO_CTL	0x01E2 C000	290	0010E1B7
DDR_SLEW	0x01E2 C004	292	00000000

What should I try next?"

Thanks,

Daniel

0 Brad Griffis over 5 years ago in reply to Daniel Carlson

TI__Guru*** 125430 points

Daniel Carlson said:
Column Addressing2K A11, A[9:0]

This appears to be the main difference between the two LPDDR part numbers. The new one has an additional column address bit (a11).

Daniel Carlson said:

SDCR (addres 0xB000 0008) = 0A034622

Tried 0A034623

Writing 0x23 to 0xB0000008 crashes u-boot

This looks like you are headed in the right direction. Clearly the page size needs to be updated. We need to better understand why it's crashing. I recommend sticking a while(1) loop immediately after the DDR configuration and connecting with CCS to explore whether the DDR seems to be functioning correctly or not. If it is not functioning correctly, we need to better understand how it is failing. I expect that this change to the column addressing should fix the aliasing issue, though it's possible there's some other DDR-related issue (e.g. bits flipping, etc.).

Processors

Processors forum

OMAP-L138: 256MB DDR memory problem