Upgrading RAM from 128MB to 256MB on imx27

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Upgrading RAM from 128MB to 256MB on imx27

584 Views
joshcollins
Contributor II

I have a system based on an i.MX27L. This system is running redboot and Linux 2.6.28. Currently the system is using a 128MB SDRAM (MT46H32M32LF) which we need to upgrade to 256MB (MT46H64M32LF). I have managed to get the system to see all 256MB of ram by:

 

--- a/ecos/packages/hal/arm/mx27/3stack/current/include/fsl_board.h
+++ b/ecos/packages/hal/arm/mx27/3stack/current/include/fsl_board.h

-#define SDRAM_SIZE 0x08000000
+#define SDRAM_SIZE 0x10000000

 

I also modified (however I do not know if this is needed for the linux system):

 

--- a/ecos/packages/hal/arm/mx27/3stack/current/include/pkgconf/mlt_arm_board_romram.h
+++ b/ecos/packages/hal/arm/mx27/3stack/current/include/pkgconf/mlt_arm_board_romram.h

-#define CYGMEM_REGION_ram_SIZE (0x7F00000)
+#define CYGMEM_REGION_ram_SIZE (0xFF00000)

-#define CYGMEM_REGION_rom (0xA7F00000)
+#define CYGMEM_REGION_rom (0xAFF00000)

--- a/ecos/packages/hal/arm/mx27/3stack/current/include/pkgconf/mlt_arm_board_romram.ldi
+++ b/ecos/packages/hal/arm/mx27/3stack/current/include/pkgconf/mlt_arm_board_romram.ldi

-    ram : ORIGIN = 0, LENGTH = 0x7F00000
-    rom : ORIGIN = 0xA7F00000, LENGTH = 0x100000
+    ram : ORIGIN = 0, LENGTH = 0xFF00000
+    rom : ORIGIN = 0xAFF00000, LENGTH = 0x100000

-    SECTION_rom_vectors (rom, 0xA7F00000, LMA_EQ_VMA)
+    SECTION_rom_vectors (rom, 0xAFF00000, LMA_EQ_VMA)

--- a/ecos/packages/hal/arm/mx27/3stack/current/include/plf_mmap.h
+++ b/ecos/packages/hal/arm/mx27/3stack/current/include/plf_mmap.h

-    if ( _v_ < 128 * SZ_1M )          /* SDRAM */                           \
+    if ( _v_ < 256 * SZ_1M )          /* SDRAM */                           \

--- a/ecos/packages/hal/arm/mx27/3stack/current/src/board_misc.c
+++ b/ecos/packages/hal/arm/mx27/3stack/current/src/board_misc.c

-    X_ARM_MMU_SECTION(0xA00, 0x000,   0x080, ARM_CACHEABLE,   ARM_BUFFERABLE,   ARM_ACCESS_PERM_RW_RW); /* SDRAM */
-    X_ARM_MMU_SECTION(0xA00, 0xA00,   0x080, ARM_CACHEABLE,   ARM_BUFFERABLE,   ARM_ACCESS_PERM_RW_RW); /* SDRAM */
-    X_ARM_MMU_SECTION(0xA00, 0xA80,   0x080, ARM_UNCACHEABLE, ARM_UNBUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* SDRAM */
+    X_ARM_MMU_SECTION(0xA00, 0x000,   0x100, ARM_CACHEABLE,   ARM_BUFFERABLE,   ARM_ACCESS_PERM_RW_RW); /* SDRAM */
+    X_ARM_MMU_SECTION(0xA00, 0xA00,   0x100, ARM_CACHEABLE,   ARM_BUFFERABLE,   ARM_ACCESS_PERM_RW_RW); /* SDRAM */
+    X_ARM_MMU_SECTION(0xA00, 0xB00,   0x100, ARM_UNCACHEABLE, ARM_UNBUFFERABLE, ARM_ACCESS_PERM_RW_RW); /* SDRAM */

 

When the system boots up, the OS can see all the RAM:

 

$ free -m

total used free shared buffers
Mem: 255528 45456 210072 0 0
-/+ buffers: 45456 210072
Swap: 0 0 0

 

However, when I try to allocate the memory, the system hangs. I cannot communicate with the system without a hard reboot (power toggle). I have attached the source code for a simple C++ test that I use to allocate a block of memory. When I try to allocate past 128MB, the system freezes. It does not matter if I try to allocate from a single process or a number of individual processes, when i exceed the 128MB limit for the system, I get the hang.

 

I believe that the RAM hardware is valid, because I tried to test from redboot:

 

RedBoot> x -b 0x0feffff0 -l 16

0FEFFFF0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |................|

RedBoot> mfill -b 0x0feffff0 -l 16 -p 1
RedBoot> x -b 0x0feffff0 -l 16
0FEFFFF0: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 |................|

 

 

This seems to show that I correctly can write/read from memory that is at the end of the 256MB space.

 

I use `strace` to see what system calls are made by my memory allocating program. It seems that when I allocate over the 128MB, the system finishes a mmap2 call, but then hangs. This answer on Stack Overflow  made me wonder if the attributes for the memory regions are invalid, but I was not sure how to further debug if this was the case.

 

I have also read through this thread: How to put i.mx28 with DDR2 256MB ? but I cannot find usages of the HW_DRAM_CTL29  define in either the bootloader or kernel, so I assume that this might be specific to the i.MX28 rather than i.MX27.

 

At this stage I am very unsure how to proceed. It is not clear to me if the issue lies in the bootloader, the kernel, or maybe even something in the root filesystem. If anyone has any suggestions for what could be causing this behaviour or suggestions on how I can further debug the issue that would be greatly appreciated.

Original Attachment has been moved to: strace_failed_allocation.txt.zip

Original Attachment has been moved to: strace_successful_allocation.txt.zip

Original Attachment has been moved to: t5-memory-test.cpp.zip

Labels (2)
0 Kudos
1 Reply

402 Views
igorpadykov
NXP Employee
NXP Employee

Hi Josh

please look at attached redboot 256MB (for two CSDx  x128MB) patch

for i.MX35 PDK, it will help to understand which files should be modified.

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

0 Kudos