• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1225 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Auto detection of Kernel Load Address and Run Time RAM Base Determination

Badri Narayanan
Guru 59700 points

I am trying to use the feature "Auto detection of Kernel Load Address and Run Time RAM Base Determination" as described in

http://processors.wiki.ti.com/index.php/DM816x_AM389x_PSP_User_Guide#Auto_detection_of_Kernel_Load_Address_and_Run_Time_RAM_Base_Determination

The following are the steps followed:

1. Confirmed menuconfig has

   [*] Patch physical to virtual translations at run time (EXPERIMENTAL)

   [*] Auto calculation of the decompressed kernel image address

   enabled.

2. Built uImage using:

      make CROSS_COMPILE=/datalocal/ti_tools/cgt_a8/arm-2009q1/bin/arm-none-linux-gnueabi- ARCH=arm zreladdr-y=0xE0008000 uImage

    Build log below:

      UIMAGE  arch/arm/boot/uImage
      Image Name:   Linux-2.6.37+
      Created:      Thu Oct 18 20:05:48 2012
      Image Type:   ARM Linux Kernel Image (uncompressed)
      Data Size:    2581544 Bytes = 2521.04 kB = 2.46 MB
      Load Address: 0xE0008000
      Entry Point:  0xE0008000
      Image arch/arm/boot/uImage is ready

Kernel hangs at boot up time with below log:

TFTP from server 172.24.136.217; our IP address is 172.24.191.63; sending through gateway 172.24.188.1
Filename 'uImage'.
Load address: 0x81000000
Loading: T #################################################################
         #################################################################
         ##############################################
done
Bytes transferred = 2581608 (0x276468)
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-2.6.37+
   Created:      2012-10-18  14:35:48 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2581544 Bytes = 2.5 MiB
   Load Address: e0008000
   Entry Point:  e0008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...
  ----- HANG HERE ----

I confirmed the physical address 0xE0000000 is readable and writeable from uboot  and the board has 2GB memory.

I connected CCS and control was in panic function but the kernel image seems to have loaded correctly .For example, viewing linux_banner shows the correct value in memory.

Pls let me know what I am doing wrong.

  • 0
    TI__Guru 59700 points

    Some additional info. Kernel boots up with the following addresses:

    Load Address: 0xC0008000 - OK (Kernel Boots up)

    Load Address: 0xC8008000 - OK (Kernel Boots up)

    Load Address: 0xD0008000 - NOT OK (Hang in starting kernel)

    Load Address: 0xE0008000 - NOT OK (Hang in starting kernel)

     

  • 0 in reply to Badri Narayanan
    TI__Mastermind 40976 points

    Badri,

    Do you get the answer of the question? My customer asked similar question now.

  • 0 in reply to Chris Meng
    TI__Guru 59700 points

    I didn't get answer to my questions but got some info from

    http://www.arm.linux.org.uk/developer/memory.txt

    http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062610.html

    It appears placing the kernel beyond 0xD000_0000 with mem=512M causes conflict with default kernel memory mapping resulting in unbootable kernel.

    I didn't debug this further. We use 0xC000_0000 as kernel base address in dvrrdk which works fine.

  • 0 in reply to Badri Narayanan
    TI__Mastermind 40976 points

    Badri,

    Thanks for your reply.

    My customer wants to use 2GB DDR and let M3 accesses 1.5GB DDR. I found below limitation for M3, do you know if the address below refer to logical address for M3 or physical/system address?

      1. Media Controller cannot access any program memory above 0xA0000000.
      2. Media Controller cannot access any data memory above 0xE0000000

     I think it should be for logical address. Would you pls confirm?

    If it is for logical address, I think customer can remap the system address 0xE0000000 to logical address 0xC0000000 for M3 to access.

    If not, do you have any idea to let M3 to support 1.5GB DDR?