This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

256 Mbyte Low Power DDR detection in kernel space

Other Parts Discussed in Thread: DM3730

Hi all, 

I would like a clarification on how to recognize the system right size of ram in Kernel Space.

I have a DM3730 and it's equipped with 256Mb of Low Power DDR (MICRON MT46H64M32). I'm using  Kernel version 2.6.32, DVSDK ti-dvsdk_dm3730-evm_4_02_00_06, configured for omap3 Evm board.

I was initially able to access only 128 Mb of RAM.

In the x-loader and in the U-boot I found where to make changes in the source code, and now I can read and write all 256Mbytes (using "md" and "mw" in U-boot for example).

In the u-boot source I changed sdrc.c (row 110) changing RAMSIZE_128 with RAMSIZE_256; and the value of the sdrc controller register is set to 0x02588099.

See the u-boot screenshot:

-----------------------------------------------------------------------------------------------------------

U-Boot 2009.11 (Apr 22 2013 - 17:47:03)                                         
                                                                                
AM37x/DM37x-GP ES2.1, CPU-OPP2 L3-165MHz                                        
OMAP3 EVM board + LPDDR/NAND                                                    
I2C:   ready                                                                    
DRAM:  256 MB                                                                                                                                                                     

--------------------------------------------------------------------------------------------------------------

 

But when Kernel starts I can access only first 128Mb of RAM.

In particular: i turned off: cmem, dsplink, sdma, ecc... disabling them in  loadmodule-rc.

If I use bootargs:

setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 ip=off mem=128M@0x80000000 omapfb.vram=0:4M rootwait'
fatload mmc 0 82000000 uImage
bootm 82000000

kernel starts correctly  but, obiovsly, i can see only 128Mb of RAM.

 

If I use, for example,  bootargs:

setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 ip=off mem=100M@0x80000000 omapfb.vram=0:4M mem=100M@0x88000000 rootwait'
fatload mmc 0 82000000 uImage
bootm 82000000

kernel hangs before login prompt. And this happens with any size of mapped memory from 0x88000000 or setting more than 128Mb from 0x80000000.

 

Thanks in advance for any suggestion,

 

Lorenzo

  • Hi Lorenzo,

    Could you try to boot with prebuilt images from dvsdk 4.02.00.06 and boot.scr from the attachment.

    http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/537/6305.boot.scr

    The whole memory should be recognized by default. If the whole memory (256 MB) is not found the board should has some hardware problem.

    BR

    Tsvetolin Shulev

  • Cvetolin hello and thanks for the quick response!

    I would exclude the hardware problem since, in the boot, I can access the entire memory (for example: mw.w 88000000 1234 and md.w 88000000 work fine).

    It may be that, during loading, the kernel changes the mux or otherwise change the configuration of the RAM?

    I have a custom hardware which, however, has been designed following the model of the mistral evm rev-g.

    Using bootargs you suggested I get a kernel crash, before it is presented with the login prompt.

    Thanks, Lorenzo

  • The dm3730emv board supports 256 MB RAM with default software therefore you should focus on the differences between your board and dm3730emv. Maybe there could find the reason for incorrect recognition of the memory volume. 

    BR

    Tsvetolin Shulev

  • Lorenzo,

    Have you tried with the bootargs 'mem=200M@0x80000000'? I assume that you've already disabled cmem etc.. 

    Also can you do one more experiment. 

    Can you write from 0x8000_0000 and try to read from 0x8800_0000 and see whether any similar patterns are observed in both the cases? The memory test you've done is not sufficient. You are just doing write and seeing whether it doesn't hang or not. But there can be memory configuration issues (page size, banks etc.) where when you write to one location it gets duplicated and gets written to another location. To figure out all these you need to do a thorough memory test. 


  • Hello Thomas,

    thank you for the reply.

    I tried several combinations of boot including also 200M @ 80000000. I also tried to use combinations where the total memory was less than 128 (ex: 40M @80000000 and 40M@88000000). But every time I use the upper memory address (> = 88000000), the system will not start.

    I agree with you that the test in question is not sufficient to rule out a hardware problem at all, which is why I run a complete test from the u-boot:

    mtest 83000000 90000000 AA 1

    and did not report any error in memory. I also went to manually verify that the memory was written on the correct pattern (in both parties) and everything is OK: incremental pattern was different for the two blocks, excluding the possibility that the same data is duplicated.

    I am increasingly convinced that at the kernel level there is a problem with the configuration of RAM, even if I can not find a match on the WEB ... maybe some kind of workarond in sources.

    However, if you use the same files: MLO, u-boot and uImage and load the same file system on demoboard the problem does not exist.



  • Lorenzo,

    Can you load the uImage to 0x8800_0000 and above and give only mem=64M@0x8000_0000 and see?