AnsweredAssumed Answered

Problems configuring 2-Channel LPDDR2 on i.MX6Q

Question asked by Steffen Doster on May 12, 2015
Latest reply on Jun 15, 2015 by Steffen Doster

Like • Show 0 Likes0
Comment • 9

Hi,

I'm developing on a custom i.MX6Q-Board and we want to use a 2-Channel LPDDR2 configuration with two Micron MT42L128M32D1TK chips (512MB per chip).

But I'm nearly running mad with this because either u-boot shows only the half size of the RAM, crashes at RAM-calculation or doesn't even start. Oh, and I forgot the fourth case: I can even start Linux and everything tells me that the system now has 1GB, but I can't believe that because my system crashes when I test the RAM with

[CODE]

memtester 300 1

[/CODE]

I also think this is the reason why I can see the login-screen, but X-Server crashes when I try to login.

Short summary of my environment:

Debugger: Trace32

Bootloader: U-Boot 2015.01

Boot-Device: SD-Card

Linux: 3.19

Distribution: Debian 8

I hope, the connections between CPU and RAM are OK. I attached the schematic in a pdf-file.

I used the LPDDR2 Script Aid to get a somehow working configuration. I think everything is adjusted correctly, but if I use it the way it is now configured, U-Boot and Linux tell me that there are only 512MB RAM.

I also tried to set "Number of Chip Selects used per Channel" to 2, but this already crashes at boot of u-boot.

The resulting .cfg-file is sie_mx6q_ScriptAid.cfg.

I tried to configure a .cfg-file for U-Boot by my own. With this, the i.MX6 "thinks" it has 1GB of Memory and even boots to Login-Screen, but crashes on memtester (see above).

My own try is in sie_mx6q.cfg.

What am I doing wrong? Or what didn't I understood?

Do you need further information?

Original Attachment has been moved to: sie_mx6q.cfg.zip

Original Attachment has been moved to: sie_mx6q-ScriptAid.cfg.zip

Steffen Doster May 28, 2015 7:23 AM

Correct Answer

YESSSSS, I DID IT!!!!!!! IT WORKS!!!!!!

This is how I solved my problem:
1. I had to activate the GPIOs to override the Fuses on 0x450 by setting BOOT_MODE to '01' (not really nessesary but helpful to play with fuses).
Note to me: I think BOOT_MODE '10' is better for my purposes -> test it later.

2. Set "DDR Memory Map default config" in BOOT_CFG3 to '10' with the now active GPIOs. This activates interleaving mode for LPDDR2 to achieve a continous memory.

3. Change the Script-Aid:
The memory doesn't have two chip-selects. Although there are two CS-Pins, only one is active!
Activate Interleaving mode

4. Change RAM-Size calculation in board specific C-File for U-Boot: The function "imx_ddr_size()" ignores two-channel-mode. So you have to set:

gd->ram_size = (imx_ddr_size()*2); //imx_ddr_size() ignores two channel mode. So double the size here! (!!!!!quick and dirty code!!!!!)

5. In device tree set the memory to a start-address of 0x10000000 (Base Address of MMDC0) and the range to 0x40000000 (1GiB).

As I remember, this was all I had to do.

I hope this helps someone else, too.

Thanks

See the reply in context

Attachments

RAM - Micron - Mobile LPDDR2 SDRAM.pdf7.0 MB
Mx6DQSDL LPDDR2 Script Aid V0.04-new.xlsx98.5 KB
IMX6Q-MT42L128M32D1TK.pdf185.0 KB

1 person had this question

Outcomes

Vijai Kumar May 14, 2015 8:06 AM

Hi Steffan,

We are also facing similar issues in our custom board, in our case the part number is MT42L128M64D2 instead of two MT42L128M32D1TK.

"I tried to configure a .cfg-file for U-Boot by my own. With this, the i.MX6 "thinks" it has 1GB of Memory and even boots to Login-Screen, but crashes on memtester"

Can you provide a detailed boot-log for the above?

What is the maximum amount of memory you were able to test using memtester without getting the system to crash? We were able to get 130 MB above that system crashes.

Kindly provide the output of cat /proc/meminfo.

Actions

Steffen Doster @ Vijai Kumar on May 18, 2015 2:16 AM

I have two cases:

1. RAM configured with script-aid:

Crashes even with 100MB (throws some Kernel Messages of different types)

proc/meminfo:

MemTotal: 500232 kB

MemFree: 351900 kB

MemAvailable: 420404 kB

Buffers: 13968 kB

Cached: 64872 kB

SwapCached: 0 kB

Active: 79892 kB

Inactive: 41976 kB

Active(anon): 43320 kB

Inactive(anon): 6720 kB

Active(file): 36572 kB

Inactive(file): 35256 kB

Unevictable: 0 kB

Mlocked: 0 kB

HighTotal: 0 kB

HighFree: 0 kB

LowTotal: 500232 kB

LowFree: 351900 kB

SwapTotal: 0 kB

SwapFree: 0 kB

Dirty: 16 kB

Writeback: 0 kB

AnonPages: 43028 kB

Mapped: 35328 kB

Shmem: 7016 kB

Slab: 15988 kB

SReclaimable: 8040 kB

SUnreclaim: 7948 kB

KernelStack: 712 kB

PageTables: 600 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 250116 kB

Committed_AS: 89284 kB

VmallocTotal: 1548288 kB

VmallocUsed: 5532 kB

VmallocChunk: 1361448 kB

CmaTotal: 16384 kB

CmaFree: 11876 kB

2. RAM configured somehow by myself:

Crashes with 220MB. Until then it seems to work fine.

proc/meminfo:

MemTotal: 1020012 kB

MemFree: 868568 kB

MemAvailable: 933736 kB

Buffers: 14020 kB

Cached: 67076 kB

SwapCached: 0 kB

Active: 79464 kB

Inactive: 44540 kB

Active(anon): 43200 kB

Inactive(anon): 9000 kB

Active(file): 36264 kB

Inactive(file): 35540 kB

Unevictable: 0 kB

Mlocked: 0 kB

HighTotal: 0 kB

HighFree: 0 kB

LowTotal: 1020012 kB

LowFree: 868568 kB

SwapTotal: 0 kB

SwapFree: 0 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages: 42840 kB

Mapped: 35020 kB

Shmem: 9296 kB

Slab: 15940 kB

SReclaimable: 7928 kB

SUnreclaim: 8012 kB

KernelStack: 688 kB

PageTables: 588 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 510004 kB

Committed_AS: 91932 kB

VmallocTotal: 1024000 kB

VmallocUsed: 5532 kB

VmallocChunk: 837176 kB

CmaTotal: 16384 kB

CmaFree: 11876 kB

Actions

Vijai Kumar @ Steffen Doster on May 22, 2015 7:33 AM

Hi Steffen,

Have you calibrated the DDR for your board. If not can you use DDR Stress test to do a read and write calibration and see the result.

Thanks

Vijai Kumar K

Actions

Steffen Doster @ Vijai Kumar on May 26, 2015 5:46 AM

I was able to start the stress tester without any problems. It gave me some calibration values (0x403A383B) which are close to the default values (0x40404040) of the script-aid. due to the big distance to failure-values I kept the default values even if they are not optimal.

In the meantime I made another observation:

I read the RAM in u-boot using md. And this indicates me, that the RAM seems to be repeated every 512MiB.

By this way, everytime I try to write into the "upper" 512MiB it writes into the "lower" 512MiB. And this is often the place where the Kernel and other important things reside. This seems to be the reason, Linux crashes on trying "memtester 300 1".

I also think this may be an error caused by wrong fuses, because "DDR Memory Map default config" is set to 0x00 in my fuses (see attached fuse-values) and this should be 0x01 or 0x10.

And this leads to another problem of mine:
How do I activate the GPIOs for overwriting the Fuses. I attached some DIP-Switches to the relevant EIM-Pads and I switched to BOOT_MODE[1:0] = 0b10. As you can see, BT_FUSE_SEL is set to 0. I think this must be enough to activate the external GPIOs for booting.

But I thought I now can see the Values of the GPIOs in Register 0x450. Where can I see the settings I made? Or what else do I have to set?

BOOT_MODE_0 = Pad C12, BOOT_MODE_1 = Pad F12 is correct?

Attachments

Original Fuses.png52.8 KB

Actions

Vijai Kumar @ Steffen Doster on May 26, 2015 5:56 AM

Hi Steffen Doster

It is now evident that we are facing the same issue with our boards. I have started a discussion in the following location.

Failed to execute /init (error -8) during android bringup

You can refer it. I have a hardware with modified boot fuses. Meanwhile, I will test in that hardware and will get back to you if I get any improvements. Hope someone from Freescale helps us.

Thanks

Vijai Kumar K

Actions

Yuri Muhin

May 27, 2015 11:13 PM

Hello,

For Your 2-channel LPDDR2 configuration :
CS0 (channel 0) is responsible for the following address range of 512 MB : 0x1000_0000 - (0x3000_0000 - 1)

CS1 (channel 1) is responsible for the following address range of 512 MB : 0x8000_0000 - (0xA000_0000 - 1)

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Actions

Steffen Doster May 28, 2015 7:23 AM

YESSSSS, I DID IT!!!!!!! IT WORKS!!!!!!

2. Set "DDR Memory Map default config" in BOOT_CFG3 to '10' with the now active GPIOs. This activates interleaving mode for LPDDR2 to achieve a continous memory.

3. Change the Script-Aid:
The memory doesn't have two chip-selects. Although there are two CS-Pins, only one is active!
Activate Interleaving mode

4. Change RAM-Size calculation in board specific C-File for U-Boot: The function "imx_ddr_size()" ignores two-channel-mode. So you have to set:

gd->ram_size = (imx_ddr_size()*2); //imx_ddr_size() ignores two channel mode. So double the size here! (!!!!!quick and dirty code!!!!!)

5. In device tree set the memory to a start-address of 0x10000000 (Base Address of MMDC0) and the range to 0x40000000 (1GiB).

As I remember, this was all I had to do.

I hope this helps someone else, too.

Thanks

Attachments

Mx6DQSDL LPDDR2 Script Aid V0.04-new.xlsx98.5 KB

Actions

Vijai Kumar @ Steffen Doster on Jun 10, 2015 2:32 AM

Thanks Steffen Doster for coming back to the community and sharing your solution. I was also able to solve it. I used fixed 2x32 mapping instead of interleaving.

Actions

Steffen Doster Jun 15, 2015 7:45 AM

OK, there seem to be another issue with this LPDDR2 configuration:

I tried to boot from SD1 for a very, very, very long time now. But It simply doesn't start from SD-Card.

Now I think I know a little bit more about the problem:
The Bootloader isn't written correctly into RAM. Perhaps the RAM-Initialization is buggy. But I did the RAM-Configuration with the script-aid.

I want to use the 2 channel LPDDR2 in interleaving mode.

The symptoms:

I can't start from SD-Card. (Also I can not start from eMMC)
After a long reasearch, I figured out, that the RAM isn't written correctly:
Every "odd" 4kB of Data in it are corrupt.
I added an example Memorydump with loaded U-boot Data. The upper one shows the Memory how it should be, the lower one shows the end of a "even" 4kB block which is OK, while the beginning of the following "odd" 4kB block is corrupt:
some of the data which had to be written to "the left" are written to "the right".

And this seems to be the reason, why u-boot doesn't start.
As I see, the configuration written to MMDC seems to be correct. My configuration and initialzation is attached in myboard.cfg.

Also the same configuration started by JTAG does work and start u-boot.

Is there a Timing Issue with the "faster" start from SD? How can I slow down the execution of myboard.cfg? Or Can I veryfy the correct setting?

Attachments

myboard.cfg.zip3.0 KB
Memorydumps.png104.4 KB

Actions

9 Replies

Vijai Kumar May 14, 2015 8:06 AM
Mark Correct
Correct Answer
Hi Steffan,
We are also facing similar issues in our custom board, in our case the part number is MT42L128M64D2 instead of two MT42L128M32D1TK.

"I tried to configure a .cfg-file for U-Boot by my own. With this, the i.MX6 "thinks" it has 1GB of Memory and even boots to Login-Screen, but crashes on memtester"
Can you provide a detailed boot-log for the above?
What is the maximum amount of memory you were able to test using memtester without getting the system to crash? We were able to get 130 MB above that system crashes.
Kindly provide the output of cat /proc/meminfo.
Like • Show 0 Likes0
Actions
- Steffen Doster @ Vijai Kumar on May 18, 2015 2:16 AM
  Mark Correct
  Correct Answer
  I have two cases:
  1. RAM configured with script-aid:
       Crashes even with 100MB (throws some Kernel Messages of different types)
       proc/meminfo:
  MemTotal:         500232 kB
  MemFree:          351900 kB
  MemAvailable:     420404 kB
  Buffers:           13968 kB
  Cached:            64872 kB
  SwapCached:            0 kB
  Active:            79892 kB
  Inactive:          41976 kB
  Active(anon):      43320 kB
  Inactive(anon):     6720 kB
  Active(file):      36572 kB
  Inactive(file):    35256 kB
  Unevictable:           0 kB
  Mlocked:               0 kB
  HighTotal:             0 kB
  HighFree:              0 kB
  LowTotal:         500232 kB
  LowFree:          351900 kB
  SwapTotal:             0 kB
  SwapFree:              0 kB
  Dirty:                16 kB
  Writeback:             0 kB
  AnonPages:         43028 kB
  Mapped:            35328 kB
  Shmem:              7016 kB
  Slab:              15988 kB
  SReclaimable:       8040 kB
  SUnreclaim:         7948 kB
  KernelStack:         712 kB
  PageTables:          600 kB
  NFS_Unstable:          0 kB
  Bounce:                0 kB
  WritebackTmp:          0 kB
  CommitLimit:      250116 kB
  Committed_AS:      89284 kB
  VmallocTotal:    1548288 kB
  VmallocUsed:        5532 kB
  VmallocChunk:    1361448 kB
  CmaTotal:          16384 kB
  CmaFree:           11876 kB
  
  2. RAM configured somehow by myself:
      Crashes with 220MB. Until then it seems to work fine.
       proc/meminfo:
  MemTotal:        1020012 kB
  MemFree:          868568 kB
  MemAvailable:     933736 kB
  Buffers:           14020 kB
  Cached:            67076 kB
  SwapCached:            0 kB
  Active:            79464 kB
  Inactive:          44540 kB
  Active(anon):      43200 kB
  Inactive(anon):     9000 kB
  Active(file):      36264 kB
  Inactive(file):    35540 kB
  Unevictable:           0 kB
  Mlocked:               0 kB
  HighTotal:             0 kB
  HighFree:              0 kB
  LowTotal:        1020012 kB
  LowFree:          868568 kB
  SwapTotal:             0 kB
  SwapFree:              0 kB
  Dirty:                 0 kB
  Writeback:             0 kB
  AnonPages:         42840 kB
  Mapped:            35020 kB
  Shmem:              9296 kB
  Slab:              15940 kB
  SReclaimable:       7928 kB
  SUnreclaim:         8012 kB
  KernelStack:         688 kB
  PageTables:          588 kB
  NFS_Unstable:          0 kB
  Bounce:                0 kB
  WritebackTmp:          0 kB
  CommitLimit:      510004 kB
  Committed_AS:      91932 kB
  VmallocTotal:    1024000 kB
  VmallocUsed:        5532 kB
  VmallocChunk:     837176 kB
  CmaTotal:          16384 kB
  CmaFree:           11876 kB
  Like • Show 0 Likes0
  Actions
  - Vijai Kumar @ Steffen Doster on May 22, 2015 7:33 AM
    Mark Correct
    Correct Answer
    Hi Steffen,
    Have you calibrated the DDR for your board. If not can you use DDR Stress test to do a read and write calibration and see the result.
    
    Thanks
    Vijai Kumar K
    Like • Show 0 Likes0
    Actions
    - Steffen Doster @ Vijai Kumar on May 26, 2015 5:46 AM
      Mark Correct
      Correct Answer
      I was able to start the stress tester without any problems. It gave me some calibration values (0x403A383B) which are close to the default values (0x40404040) of the script-aid. due to the big distance to failure-values I kept the default values even if they are not optimal.
      
      In the meantime I made another observation:
      I read the RAM in u-boot using md. And this indicates me, that the RAM seems to be repeated every 512MiB.
      By this way, everytime I try to write into the "upper" 512MiB it writes into the "lower" 512MiB. And this is often the place where the Kernel and other important things reside. This seems to be the reason, Linux crashes on trying "memtester 300 1".
      
      I also think this may be an error caused by wrong fuses, because "DDR Memory Map default config" is set to 0x00 in my fuses (see attached fuse-values) and this should be 0x01 or 0x10.
      And this leads to another problem of mine:
      How do I activate the GPIOs for overwriting the Fuses. I attached some DIP-Switches to the relevant EIM-Pads and I switched to BOOT_MODE[1:0] = 0b10. As you can see, BT_FUSE_SEL is set to 0. I think this must be enough to activate the external GPIOs for booting.
      But I thought I now can see the Values of the GPIOs in Register 0x450. Where can I see the settings I made? Or what else do I have to set?
      BOOT_MODE_0 = Pad C12, BOOT_MODE_1 = Pad F12 is correct?
      Attachments
      Original Fuses.png52.8 KB
      Like • Show 0 Likes0
      Actions
      - Vijai Kumar @ Steffen Doster on May 26, 2015 5:56 AM
        Mark Correct
        Correct Answer
        Hi Steffen Doster
        It is now evident that we are facing the same issue with our boards. I have started a discussion in the following location.
        Failed to execute /init (error -8) during android bringup
        You can refer it. I have a hardware with modified boot fuses. Meanwhile, I will test in that hardware and will get back to you if I get any improvements. Hope someone from Freescale helps us.
        
        Thanks
        Vijai Kumar K
        Like • Show 0 Likes0
        Actions
Yuri Muhin May 27, 2015 11:13 PM
Mark Correct
Correct Answer
Hello,

For Your 2-channel LPDDR2 configuration :
CS0 (channel 0) is responsible for the following address range of 512 MB : 0x1000_0000 - (0x3000_0000 - 1)
CS1 (channel 1) is responsible for the following address range of 512 MB : 0x8000_0000 - (0xA000_0000 - 1)

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Like • Show 0 Likes0
Actions
Steffen Doster May 28, 2015 7:23 AM
Unmark Correct
Correct Answer
YESSSSS, I DID IT!!!!!!! IT WORKS!!!!!!

This is how I solved my problem:
1. I had to activate the GPIOs to override the Fuses on 0x450 by setting BOOT_MODE to '01' (not really nessesary but helpful to play with fuses).
    Note to me: I think BOOT_MODE '10' is better for my purposes -> test it later.
2. Set "DDR Memory Map default config" in BOOT_CFG3 to '10' with the now active GPIOs. This activates interleaving mode for LPDDR2 to achieve a continous memory.
3. Change the Script-Aid:
    The memory doesn't have two chip-selects. Although there are two CS-Pins, only one is active!
    Activate Interleaving mode
4. Change RAM-Size calculation in board specific C-File for U-Boot: The function "imx_ddr_size()" ignores two-channel-mode. So you have to set:
    gd->ram_size = (imx_ddr_size()*2); //imx_ddr_size() ignores two channel mode. So double the size here! (!!!!!quick and dirty code!!!!!)
5. In device tree set the memory to a start-address of 0x10000000 (Base Address of MMDC0) and the range to 0x40000000 (1GiB).

As I remember, this was all I had to do.

I hope this helps someone else, too.

Thanks
Attachments
- Mx6DQSDL LPDDR2 Script Aid V0.04-new.xlsx98.5 KB
Like • Show 0 Likes0
Actions
- Vijai Kumar @ Steffen Doster on Jun 10, 2015 2:32 AM
  Mark Correct
  Correct Answer
  Thanks Steffen Doster for coming back to the community and sharing your solution. I was also able to solve it. I used fixed 2x32 mapping instead of interleaving.
  Like • Show 0 Likes0
  Actions
Steffen Doster Jun 15, 2015 7:45 AM
Mark Correct
Correct Answer
OK, there seem to be another issue with this LPDDR2 configuration:

I tried to boot from SD1 for a very, very, very long time now. But It simply doesn't start from SD-Card.
Now I think I know a little bit more about the problem:
The Bootloader isn't written correctly into RAM. Perhaps the RAM-Initialization is buggy. But I did the RAM-Configuration with the script-aid.

I want to use the 2 channel LPDDR2 in interleaving mode.

The symptoms:
1. I can't start from SD-Card. (Also I can not start from eMMC)
2. After a long reasearch, I figured out, that the RAM isn't written correctly:
  Every "odd" 4kB of Data in it are corrupt.
  I added an example Memorydump with loaded U-boot Data. The upper one shows the Memory how it should be, the lower one shows the end of a "even" 4kB block which is OK, while the beginning of the following "odd" 4kB block is corrupt:
  some of the data which had to be written to "the left" are written to "the right".
And this seems to be the reason, why u-boot doesn't start.
As I see, the configuration written to MMDC seems to be correct. My configuration and initialzation is attached in myboard.cfg.
Also the same configuration started by JTAG does work and start u-boot.
Is there a Timing Issue with the "faster" start from SD? How can I slow down the execution of myboard.cfg? Or Can I veryfy the correct setting?
Attachments
- myboard.cfg.zip3.0 KB
- Memorydumps.png104.4 KB
Like • Show 0 Likes0
Actions

Problems configuring 2-Channel LPDDR2 on i.MX6Q

Attachments

Outcomes

Attachments

Attachments

Attachments

Related Content

Recommended Content

Incoming Links