How to support more RAM on i.MX28EVK?

[jimtremblay]

Hi,

     I'm relatively new in embedded Linux and i.MX processors. I have a i.MX28EVK that run the latest Linux BSP from Freescale website and I need to ensure the processor will have enough power to run everything we want. For the tests, the 128MB on the board is not enough. We have replace the chip for a 256MB. I have reboot the board with my latest SD card to ensure the RAM is properly changed and it runs fine. Now, I want to be able to access the whole 256MB from Linux. I have get u-boot source from Linux BSP and recompile it with PHYS_SDRAM_1_SIZE changed from 0x08000000 to 0x10000000 to support the whole 256MB. I have copied generated u-boot.bin to ltib/rootfs/boot/u-boot.bin and rerun the script mk_mx28_sd, but I only see 128MB in Linux when I boot from this card. I don't have access to the whole 256MB.

Then, I want to know if its possible with the EVK to do that? If yes, what I need to do to enable it?

Thanks in advance

Jim

PS: I'm using latest LTIB with Ubuntu 9.04 VM.

[AnsonHuang]

Hi, Jim

     1. Can you try to read/write some data in uboot to make sure that all 256MB memory can be accessed, using md.l 0x4a000000 10 to read the offset 160MB's data, then modify it using mw.l 0x4a000000 0x12345678 to see whether you can write 0x12345678 to it. This is to make sure the whole 256MB DDR can be accessed;

     2. If yes, when booting up kernel, you can see the log of memory info at the beginning of the kernel message, the lowmem info represent the DDR size, if it is still 128M, then I think there is something wrong with the uboot setting.

     3. Can you try ./linux_prep/include/mx28/platform.h:#define SDRAM_SIZE 0x08000000, modify it to 0x10000000?

[jimtremblay]

Hi Yongcai,

                 First, I have get imx-bootlets source, cp generated zImage from ltib and uboot file generated after modification to PHYS_SDRAM_1_SIZE, change SDRAM_SIZE in platform.h and build all 4 sb files. I have copy this files to ~/ltib/rootfs/boot/ and recreate the sd card with ./mk_mx28_sd -u /dev/sdb. When I boot, I see u-boot countdown and stop it to have the prompt. I see DRAM: 256MB When I execute the command md.l <address> 10, u-boot give a big bunch of junk and the prompt hang completely if <address> is higher or equal to 0x48000000.

I have build the sd card without -u option, then I presume the script use my imx28_ivt_linux.sb generated early, I see the startup, the decompression of linux kernel and it hang right after booting to the kernel.

Jim

Edit: Do I need to change some definitions to enable the extra address line?

Edit2: I have double check all pins are enable for RAM in imx bootlets.

[AnsonHuang]

Hi, Jim

     From what you described, seems like you can not access the DRAM address that higher tha 0x48000000, so can you first make sure that the whole 256M DRAM has been initialized? You can ignore uboot, just use bootlets to boot up kernel. We have simple DRAM test in bootlets which will read/write DRAM when bootlet boot up, you can see the log from debug message, then you can modify this DRAM test address to cover the address higher than 128M to see whether the whole 256M DRAM can beaccessed.

     To answer your questions:

     1. I think if you use bootlet to boot up kernel directly, you only need to change definition I mentioned yestoday.

     2. If you are sure all RAM are initialized correctly, please use the DRAM simple test to make sure the whole 256M DRAM can be accessed. Then all we need to do is passing the DRAM size correctly to kernel.

     Sorry that it is been long time since I developped i.MX28, I need to look into the RM for more detail information, will let you know if I have something found. But you can try fist to make sure the whole 256M DRAM can be accessed.

[jimtremblay]

Hi Yongcai,

                 I have searched in different files and I have found in boot_prep/init-mx28.c in function DDR2EmiController_EDE1116_200MHz, when the code write in dram register 29, it sets 0x0f02020a. The important part is that it sets 13 rows and 10 columns. For our 256MB (14 rows and 10 columns), I have changed this to 0x0f02010a. Now I am able to access the whole 256MB in u-boot with md.l and mw.l command. But if I boot with this modified version of bootlets, the kernel start to boot and hang right after printing "mxs_cpu_init: cpufreq init finished" to console. I have test the same zImage from previously build with bootlets for 128MB and 256MB and it works when bootlets is not modified (128MB), but it hangs when it is modified (256MB). Then, I presume I need to change other things.

Have you found something?

Jim

[AnsonHuang]

Hi, Jim

     Now if you are sure that the whole 256M DRAM can be accessed, please make sure that the address of DRAM which > 128M is not the wrapped address of the first 128M, this is too make sure we did actually have 256M DRAM and their content are independent.

     You said that kernel hang when boot up, can you try to add command "mem=128M" to uboot commandline to see whether kernel boot up successfully, I think it should be OK.

     The last thing you need to check is the kernel ATAG parameter which is passed from bootlet/uboot to kernel to let kernel know how large of DRAM we have, the address is 0x40000100, please add some debug info in arch/arm/kernel/setup.c of setup_arch routine, the mem size is a member of structure tag(tag->u.mem.size), we need to see whether this mem size is right.

     Based on my understanding, the kernel only determine the DRAM size based on the atag passed from bootloader, as long as the DRAM has been initialized and the DRAM size was told, kernel can handle all the rest.

     Sorry that I didn't have a MX28 board with 256M DRAM, so I can NOT debug it here, so I can only provide my thoughts.

[markwilliams]

Hi Jim,

I have a custom i.MX28 board running 256MB DDR2. However, I am running Windows CE 6.0 so the OS firmware changes will be different. I had to remap the windows CE virtual-physical address table to make space for the additional 128MB (I do not know Linux so I am not sure if the same applies).

I used a spreadsheet provided by Freescale to calculate the DDR2 parameters (including changing the number of address lines used as you found out). This spreadsheet needs to be filled in with the timing parameters for your DDR2 and then the register changes need to be applied to the relevant startup code.

In changing from 128MB to 256MB there are a number of timing parameters that need to be updated too.

I have an example for a Micron MT47H128M16RT-25E attached to this post.

Mark

[jimtremblay]

Hi,

     thank you for your help guys. With command md.l and mw.l I have ensure memory is not wrapped up. Memory location at 42000000 and 4a000000 are independent. I can write to 42000000 and I see my modification at 42000000 and I don't see the modification at 4a000000.

I have added mem=128M to bootlets/linux_prep/cmdlines/iMX28_EVK.txt at the end of console= line and when I boot I can see this:

Memory: 128MB = 128MB total

Memory: 120316k/120316k available, 10756k reserved, 0K highmem

Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    DMA     : 0xfde00000 - 0xffe00000   (  32 MB)

    vmalloc : 0xc8800000 - 0xf0000000   ( 632 MB)

    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)

    modules : 0xbf000000 - 0xc0000000   (  16 MB)

      .init : 0xc0008000 - 0xc0030000   ( 160 kB)

      .text : 0xc0030000 - 0xc04df000   (4796 kB)

      .data : 0xc04e0000 - 0xc051dce0   ( 248 kB)

instead of this

Memory: 256MB = 256MB total

Memory: 250264k/250264k available, 11880k reserved, 0K highmem

Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    DMA     : 0xfde00000 - 0xffe00000   (  32 MB)

    vmalloc : 0xd0800000 - 0xf0000000   ( 504 MB)

    lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)

    modules : 0xbf000000 - 0xc0000000   (  16 MB)

      .init : 0xc0008000 - 0xc0030000   ( 160 kB)

      .text : 0xc0030000 - 0xc04df000   (4796 kB)

      .data : 0xc04e0000 - 0xc051dce0   ( 248 kB)

when mem=128M is not specified. But, the kernel hang at the same place: right after "mxs_cpu_init: cpufreq init finished".

I have the same RAM as you Mark and I have updated my registers with value from the xls (little differences for timing registers), but the board continue to do the same. The kernel hang at boot-up at the same place.

I have added a printk in setup_arch function right after the block that convert old style parameters to tag list and it report a value of 0 for tags->u.mem.size with two bootlets (128MB that boot fine and 256MB that hang during boot).

Do you have any other thoughts I can experiment?

Jim

PS: I have attached the output of console for each bootlets build (128MB and 256MB).

Edit: I had read many threads and found this Re: Kernel execution stops at decompress function to learn the function that init DDR is duplicated in kernel. I have done the same modifications to this function and now, it doesn't hang at boot, but it produce a kernel panic after mounting rootfs from sd card. I have attached the console output.

[AnsonHuang · Accepted solution]

Hi, Jim

     I guess the hang you met of "mxs_cpu_init: cpufreq init finished" is caused by the emi_settings.c, you should also modify these EMI controller setting according to your 256M size DRAM, just same as you did in bootlets.

     If I remember right, on MX28, when CPUfreq is changed, the EMI clock will be also changed, and the new setting of EMI controller will be used, this is in emi_settings.c. So, you need to modify emi_settings.c according to your 256MB setting.

     Then when you met the kernel panic, I think it already went to rootfs mount, can you please try to update your rootfs? I means, can you update all of you bootlets, uboot, kernel and rootfs on your SD card?

[jimtremblay]

Hi,

     Sorry for the late response, I was away for last 3 weeks. I have do a distclean and a full rebuild after. Now it's works and I have access to the full 256MB in Linux.

Thanks all for your support

Jim

[AnsonHuang]

This is weird, from your kernel log, the DRAM size setting is right.

Can you try to build out CPUFREQ driver, I want to know where exactly system hang when using 256M memory. Disable CPUFREQ driver by menu config->CPU power management->CPUFREQ.