• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 2167 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

EVMK2H processor-sdk DDR3 CMEM and mem_reserve

Anthony Diak
Intellectual 430 points

I've recently updated to using the processor-sdk instead of MCSDK and am having some issues getting back to where I was.  I was setting mem_reserve=1024M in u-boot, but now when I set it at that I get stuck at "Starting Kernel...".  With mem_reserve=512M (default) it boots fine.

I was poking around trying to find out information, and saw this section in the kernel device tree:

        cmem_block_mem_0: cmem_block_mem@829000000 {
            reg = <0x00000008 0x29000000 0x00000000 0x17000000>;
            no-map;
            status = "okay";
        };

This seems to be going right up to 1024M (and possibly including it?): 0x8 2900 0000 + 0x0 1700 0000 = 0x8 4000 0000

and then I found this page that has this note:

Starting from Processor SDK 2.0.1.x, uboot variable, “mem_reserve”, is no longer used to reserve memory for CMEM. If you still have leftover “mem_reserve” in your uboot environment, please unset it by “setenv mem_reserve” followed by “saveenv”.


I didn't see anything in the processor-sdk about this in the migration guide, and just want to make sure the "correct" way to reserve memory for the DSP (or just to keep it away from Linux using it as memory).

Booting with mem_reserve unset gives this in /proc/iomem:

800000000-81fffffff : System RAM
  800008000-8007fb0c3 : Kernel code
  80083e000-8008a9c83 : Kernel data
822000000-828ffffff : CMEM
829000000-83fffffff : CMEM
840000000-87fffffff : System RAM

So with all that background, 2 questions:

  1. Why can't I boot with mem_reserve=1024M? The unset mem_reserve boot shows 1024M in that last system ram section.
  2. Is the correct way to remove the mem_reserve and setup my device tree to have a CMEM region that takes up 1024M to stop Linux from using it?
  • 0
    TI__Mastermind 43955 points
    Hi Anthony,

    Yes, your observation is right. if the "mem_reserve" is 1024M, it doesnot boot. If it is 512M, it boots. I have tested in K2HK EVM using processor SDK 2.0.2.

    Let me have a look at it and get back.

    Thanks for your patience.
  • 0 in reply to Shankari G
    TI__Mastermind 43955 points

    Hi Anthony Diak,

    As per the wiki given below, the mem_Reserve variable is used by the U-boot to create the memory node in the DTB to pass the memory size information in the kernel.

    Meanwhile, please do check wether this info helps .

    Refer to section, "Using more than 2GB of DDR3A memory" in

  • 0 in reply to Shankari G
    Intellectual 430 points

    Thanks for the reply.  I've looked at that wiki section before, but I am using the stock EVM (with 2GB DDR3A) configuration.  I think I understand that uboot is creating a DTB entry with the info from mem_reserve.  The old MCSDK setup worked fine when I used mem_reserve=1024M.  I don't see what the memory conflict is in the DTB with the current SDK.

  • 0 in reply to Shankari G
    Intellectual 430 points
    I have updated to the latest processor sdk for k2hk (3.03.00.04 as of this post) and still have this problem. I have also tried to make a area directly in the dts in the reserved-memory section like this:

    reserved-memory {
    reserved_1g: reserved_1g {
    reg = <0x00000008 0x40000000 0x00000000 0x40000000>;
    no-map;
    };
    }

    I also had to update cmem_block_mem_0 to only be 256M instead of the old 384M to not overlap.

    and I still get stuck at "loading kernel..."
  • 0 in reply to Anthony Diak
    Intellectual 430 points
    I was able to get it to boot by changing the size to 0x3FFFFFFF (not quite 1024M) in my reserved_1g area. Now /proc/iomem no longer lists anything 0x8_40000000 and above.

    This works, but I'm not a fan of not reserving the full 1024M.

    There must be a bug somewhere -- maybe in u-boot when its removing all the reserved memory regions (since this happens with using mem_reserve as well)? I'll be taking a look there.