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.

Linux/TDA2SX: I,m getting kernel panic if I modified mem=2048M in uenv.txt

Part Number: TDA2SX

Tool/software: Linux

Hi all,

I am working on TI EVM TDA2x board with cpu as "DRA752-GP ES2.0" & DRAM = 4GB

In the below link some discussions happened on DDR3 size and memory configuration,So with out "mem" argument in uenv.txt we can use our total available RAM set up on our Board.

http://e2e.ti.com/support/processors/f/791/p/803805/3006811#3006811

I tested with, without mem argument in uenv.txt and it is fine it is displaying total mapped memory.


root@dra7xx-evm:~# cat /proc/meminfo
MemTotal:        3717752 kB
MemFree:         3594484 kB
MemAvailable:    3648292 kB

But here,my problem is if i'm going to limit memory to 2GB with mem argument(mem=2048M) then kernel panic happened.I don't know why it happened.See the below log.

[    2.804088] Freeing unused kernel memory: 340K
[    2.808566] This architecture does not have kernel memory protection.
[    2.826244] Unhandled fault: synchronous external abort (0x210) at 0xffeee000
[    2.833411] pgd = c0003000
[    2.836128] [ffeee000] *pgd=80000080007003, *pmd=affa6003, *pte=c00000ffc0071f
[    2.843413] Internal error: : 210 [#1] PREEMPT SMP ARM
[    2.848570] Modules linked in:
[    2.851646] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.4.84-00027-g018eb62-dirty #147
[    2.859595] Hardware name: Generic DRA74X (Flattened Device Tree)
[    2.865716] task: ee878000 ti: ee862000 task.ti: ee862000
[    2.871142] PC is at memcpy+0x48/0x330
[    2.874914] LR is at copy_to_iter+0x194/0x2ac
[    2.879290] pc : [<c02b0ca8>]    lr : [<c02c3750>]    psr: 60000013
[    2.879290] sp : ee863d0c  ip : 00000000  fp : ee863d5c
[    2.890816] r10: 00000000  r9 : ffeee080  r8 : ee863e2c
[    2.896061] r7 : 00000080  r6 : ee863e34  r5 : 00000080  r4 : 00000080
[    2.902614] r3 : 00000002  r2 : 00000000  r1 : ffeee000  r0 : ee308c00
[    2.909168] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    2.916507] Control: 30c5387d  Table: 80003000  DAC: 55555555
[    2.922277] Process swapper/0 (pid: 1, stack limit = 0xee862210)
[    2.928309] Stack: (0xee863d0c to 0xee864000)
[    2.932682] 3d00:                            00000080 ee863e34 00000080 ee863e2c ee308c00
[    2.940895] 3d20: 00000080 c02c3750 eed933f4 ee863d74 ee863d64 00001000 ee863e34 ffeee000
[    2.949107] 3d40: 00000000 ee5835b0 ee862000 00000000 ee863d9c ee863d60 c02c39bc c02c35c8
[    2.957321] 3d60: c00d0010 c067ee50 eff91000 eff91000 00000000 eff91000 ee583694 edc07780
[    2.965534] 3d80: 00000000 ee5835b0 ee862000 00001000 ee863e1c ee863da0 c00d19dc c02c3874
[    2.973747] 3da0: 00000001 ee3d2400 00000000 c093266c 00080001 00000000 ffffffff 00000001
[    2.981959] 3dc0: edc077e8 00000fff 00000000 ffffe000 ee863e48 ee863e34 c01cb134 c01c530c
[    2.990169] 3de0: 00000014 00000014 ee863e24 ee863df8 c0143af4 edc07780 ee863ec0 00000000
[    2.998384] 3e00: 00000000 00000080 00000000 edc0e000 ee863e8c ee863e20 c01207b4 c00d1778
[    3.006596] 3e20: 00000080 c0143aac c0111554 ee308c00 00000080 00000002 00000000 00000080
[    3.014809] 3e40: ee863e2c 00000001 edc07780 00000000 00000000 00000000 00000000 00000000
[    3.023022] 3e60: 00000000 00000000 ee308c00 edc07780 ee863ec0 c0935668 ee308c00 ee3f5000
[    3.031234] 3e80: ee863ebc ee863e90 c0120f58 c012070c 0000003f 00000000 ffffe000 00000000
[    3.039446] 3ea0: c09355e0 c0935668 ee308c00 ee3f5000 ee863edc ee863ec0 c01262ac c0120ee4
[    3.047658] 3ec0: 00000000 00000000 ee308c00 ee5835b0 ee863f04 ee863ee0 c0126e18 c0126278
[    3.055870] 3ee0: ee308c00 00000080 00000003 ee1ba000 c09355e0 c0935668 ee863f4c ee863f08
[    3.064082] 3f00: c01276fc c0126d64 c0982e58 00000000 ffffe000 00000000 00000000 00000000
[    3.072294] 3f20: c09355e0 c09355e0 c0935668 00000000 00000000 00000000 00000000 00000000
[    3.080503] 3f40: ee863f64 ee863f50 c01278cc c0127280 00000000 00000000 ee863f7c ee863f68
[    3.088715] 3f60: c000974c c01278ac c0982000 c0813728 ee863f94 ee863f80 c0009764 c000972c
[    3.096928] 3f80: c0982000 c067d630 ee863fac ee863f98 c067d6d4 c000975c 00000000 c067d630
[    3.105143] 3fa0: 00000000 ee863fb0 c000fb88 c067d63c 00000000 00000000 00000000 00000000
[    3.113355] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    3.121567] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    3.129778] Backtrace:
[    3.132244] [<c02c35bc>] (copy_to_iter) from [<c02c39bc>] (copy_page_to_iter+0x154/0x2c0)
[    3.140453]  r10:00000000 r9:ee862000 r8:ee5835b0 r7:00000000 r6:ffeee000 r5:ee863e34
[    3.148354]  r4:00001000
[    3.150909] [<c02c3868>] (copy_page_to_iter) from [<c00d19dc>] (generic_file_read_iter+0x270/0x67c)
[    3.159989]  r10:00001000 r9:ee862000 r8:ee5835b0 r7:00000000 r6:edc07780 r5:ee583694
[    3.167891]  r4:eff91000
[    3.170449] [<c00d176c>] (generic_file_read_iter) from [<c01207b4>] (__vfs_read+0xb4/0xdc)
[    3.178744]  r10:edc0e000 r9:00000000 r8:00000080 r7:00000000 r6:00000000 r5:ee863ec0
[    3.186642]  r4:edc07780
[    3.189195] [<c0120700>] (__vfs_read) from [<c0120f58>] (vfs_read+0x80/0x10c)
[    3.196357]  r9:ee3f5000 r8:ee308c00 r7:c0935668 r6:ee863ec0 r5:edc07780 r4:ee308c00
[    3.204179] [<c0120ed8>] (vfs_read) from [<c01262ac>] (kernel_read+0x40/0x54)
[    3.211341]  r9:ee3f5000 r8:ee308c00 r7:c0935668 r6:c09355e0 r5:00000000 r4:ffffe000
[    3.219165] [<c012626c>] (kernel_read) from [<c0126e18>] (prepare_binprm+0xc0/0x120)
[    3.226936]  r5:ee5835b0 r4:ee308c00
[    3.230541] [<c0126d58>] (prepare_binprm) from [<c01276fc>] (do_execveat_common+0x488/0x62c)
[    3.239010]  r7:c0935668 r6:c09355e0 r5:ee1ba000 r4:00000003
[    3.244727] [<c0127274>] (do_execveat_common) from [<c01278cc>] (do_execve+0x2c/0x34)
[    3.252587]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0935668
[    3.260484]  r4:c09355e0
[    3.263041] [<c01278a0>] (do_execve) from [<c000974c>] (run_init_process+0x2c/0x30)
[    3.270732] [<c0009720>] (run_init_process) from [<c0009764>] (try_to_run_init_process+0x14/0x44)
[    3.279637]  r5:c0813728 r4:c0982000
[    3.283246] [<c0009750>] (try_to_run_init_process) from [<c067d6d4>] (kernel_init+0xa4/0xf4)
[    3.291716]  r5:c067d630 r4:c0982000
[    3.295326] [<c067d630>] (kernel_init) from [<c000fb88>] (ret_from_fork+0x14/0x2c)
[    3.302924]  r5:c067d630 r4:00000000
[    3.306531] Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8)
[    3.312651] ---[ end trace 77b1d46e3a24be20 ]---
[    3.317287] note: swapper/0[1] exited with preempt_count 1
[    3.323144] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    3.323144]
[    3.332323] CPU0: stopping
[    3.335048] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G      D         4.4.84-00027-g018eb62-dirty #147
[    3.344216] Hardware name: Generic DRA74X (Flattened Device Tree)
[    3.350332] Backtrace:
[    3.352806] [<c00131d4>] (dump_backtrace) from [<c00133d0>] (show_stack+0x18/0x1c)
[    3.360405]  r7:c0931ef0 r6:20000193 r5:00000000 r4:c094f810
[    3.366128] [<c00133b8>] (show_stack) from [<c02b21a8>] (dump_stack+0x8c/0xa0)
[    3.373386] [<c02b211c>] (dump_stack) from [<c0016520>] (handle_IPI+0x184/0x198)
[    3.380811]  r7:c0931ef0 r6:00000000 r5:00000000 r4:c092c424
[    3.386530] [<c001639c>] (handle_IPI) from [<c00094c4>] (gic_handle_irq+0x78/0x7c)
[    3.394127]  r7:fa212000 r6:c0931ef0 r5:fa21200c r4:c09328ec
[    3.399846] [<c000944c>] (gic_handle_irq) from [<c0013ec0>] (__irq_svc+0x40/0x74)
[    3.407357] Exception stack(0xc0931ef0 to 0xc0931f38)
[    3.412428] 1ee0:                                     00000001 00000000 fe600000 00000000
[    3.420641] 1f00: c0930000 c09324ac 00000000 00000000 c0931f60 c0686284 c093250c c0931f4c
[    3.428850] 1f20: c0931f2c c0931f40 c0027fec c0010600 60000013 ffffffff
[    3.435487]  r9:c0686284 r8:c0931f60 r7:c0931f24 r6:ffffffff r5:60000013 r4:c0010600
[    3.443314] [<c00105d8>] (arch_cpu_idle) from [<c0071468>] (default_idle_call+0x28/0x34)
[    3.451442] [<c0071440>] (default_idle_call) from [<c00716c8>] (cpu_startup_entry+0x200/0x260)
[    3.460095] [<c00714c8>] (cpu_startup_entry) from [<c067d62c>] (rest_init+0x90/0x94)
[    3.467868]  r7:00000000
[    3.470426] [<c067d59c>] (rest_init) from [<c08dbd88>] (start_kernel+0x400/0x40c)
[    3.477936]  r5:c0982000 r4:c0982040
[    3.481543] [<c08db988>] (start_kernel) from [<80008090>] (0x80008090)
[    3.488103] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    3.488103]

If I'm putting mem=1024M or mem=1536M then the board is booting fine and displaying the memory info as follows.

root@dra7xx-evm:~# cat /proc/meminfo(for 1GB or mem=1024M)
MemTotal:         615952 kB
MemFree:          496928 kB
MemAvailable:     573456 kB


root@dra7xx-evm:~# cat /proc/meminfo(for 1.5G or mem=1536M)
MemTotal:        1135628 kB
MemFree:         1013800 kB
MemAvailable:    1085724 kB
Buffers:            8204 kB

Could you please help me to solve the issue. Is there any thing I need to modify/I need enable any configuration in u-boot & kernel.Please tell me.

Thanks & Regards,

A.Kavya Harini

root@dra7xx-evm:~# cat /proc/meminfo
MemTotal:         615952 kB
MemFree:          496928 kB
MemAvailable:     573456 kB

  • Interesting topic... I am not so much familiar with ARM, but I would like to get familiar (so I spent 10 minutes in total to find some viable solution).

    Here is the manual:  www.ti.com/.../sprui29f.pdf

    On the page 1516 of the manual, it states:

    • Supports 8 GiB of memory. 6GiB accessible only by the MPU (MPU-only memory) and 2GiB shared among the system. Only 4 GiB are physically available on this device. 2GiB accessible only by the MPU and 2 GiB shared among the system.

    This is self explanatory, isnt it?!

    Best Regards,

    _nobody_

     

  • Hi Kavya,

    Can you please state your final goal here?

    Your EMIF settings must be aligned to the amount of DDR available.

    Shrinking the DDR available to kernel will work fine if you don't have reserved node entries. So if you're observing kernel panics its probably due to errors while reserving carveouts in DDR from kernel. Please modify / move the reserved node entries to high-mem or shrink the reserved node size and you should notice the boot going through.


    Regards

    Shravan

  • Hi Shravan,

    My final goal is Bringing up/initializing the  DDR3. In future, we are going to work on custom board,In that board we are modifying the DDR3 chips for 4GB configuration. we are going to use total 9 "MT41K512M8" chips.In that total 9 chips, 8 chips for 4GB DDR3 and 1 chip for ECC.

    So, In our custom board to bring the DDR3 I need some Analysement on DDR3 for that ,

    1. I'm doing experiments in TI EVM board & analysing how the DDR3 is configured in uboot after generating the register values of DDR3 from EMIF tool.

    2. Regarding the memory part i'm very new to vision_sdk structure.so I want to know the memory configurations in kernel&vision_sdk.

    "Only4 GiB are physically available on this device.2GiB accessible only by the MPU and 2 GiB shared among the system." From this point I came to analyze that only 2GB is accessible by MPU(nothing but A15 Linux) and remaining 2GB is shared by all the cores including A15.Is it right?

    so if the above point is correct means if we put mem=2048M the kernel will give kernel panic because of that reserved node entries(these nodes will take around 500MB).please tell me my way of understanding is right or wrong?

    Sharvan, now I'm working on TI EVM only so EMIF settings are correctly aligned to the amount of DDR available.

    Shrinking the DDR available to kernel will work fine if you don't have reserved node entries. So if you're observing kernel panics its probably due to errors while reserving carveouts in DDR from kernel. Please modify / move the reserved node entries to high-mem or shrink the reserved node size and you should notice the boot going through.

    This point  I didn't understand very well,could you please eloborate it more.

    could you please tell me where we are limiting the 2GB access to MPU and 2GB shared for the system where this configuration is coded. I want to know how much memory is configured to linux only and for other cores.

    Thanks & Regards,

    A.Kavya Harini.

     


  • Hi Kavya,

    You can't use the 'mem=xxxx' argument to specify the amount of memory available to the kernel if its greater than or equal to 2GB.

    My guess is this argument forces usage of 1EMIF (instead of 2), and thus you notice the error. I would recommend you use the mem command-line attribute for experiments below 2G. For boards greater than 2GB, please refrain from using this attribute.

    Regards

    Shravan

  • Hi Shravan,

    ------->You can't use the 'mem=xxxx' argument to specify the amount of memory available to the kernel if its greater than or equal to 2GB.

    Regarding this point,Is there any limitation in the release of vision_sdk_03.04 for memory (mem) <= 2GB?

    -------> I want to move the Shared SR1 memory region from low-mem to high-mem.As ,mentioned in the PDF "VisionSDK_UserGuide_MemoryMap.pdf" the high-mem is non-cached region.if we move SR1 to non-cache region "Performance impact for direct CPU-access" will impact.So I want to covert the non-cache region to cache region,Is there any entries to AMMU to convert high-mem non-cache region to cache region.Please suggest me.

    Thanks & Regards,

    A.Kavya Harini.

  • Hi Kavya,

    There isn't any limitation VSDK 3.04 for DDR <= 2GB? 

    Any reason why you want to move SR-1 to high-mem? While this is possible there are quite a few changes which need to be made. Hence I would recommend keeping the SR-1 in kernels lowmem.

    Regards

    Shravan

  • Hi Shravan,

    Sorry for the late reply.

    Our custom board is designed with 4GB DDR3 in order to integrate multiple ADAS algorithm along with sensors, so this needs more size than the current size of SR-1. Hence the request to move to high-mem region.
    So,
     
    1. Could you please tell me,where I need to change the code regarding the AMMU entries for converting the non-cache region to cache-region?
     
    2. At the same time, where are the other files need to be modified while moving the SR-1 region to high-mem?

    Thanks & Regards,

    A.Kavya Harini.

  • Hi Kavya,

    What is the SR-1 size desired?

    Regards

    Shravan

  • Hi Shravan,

    Thanks for the reply.We need 1GB to 1.5GB for SR-1.

    Thanks & Regards,

    A.Kavya Harini.

  • Hi Kavya,

    It isn't possible for the M4 to access more than 512MB of cached memory. There are only 4 large page-table entries available in the IPU-AMMU. One of the entry must be for device-memory (0x40000000 - 0x60000000) , another for Tiler-mapped memory (0x60000000 - 0x80000000), another for cached region (0x80000000 - 0xA0000000) and finally for a non cached region (0xA00000000 - 0xC0000000).

    I would you reduce the amount of shared memory used, by managing the buffers consumed by your application.

    Also your issue regarding controlling memory size accessible to Linux is resolved. Please create a new thread if you have any further issues.

    Regards

    Shravan