• State
  • Locked Locked
  • Replies 16 replies
  • Subscribers 102 subscribers
  • Views 2205 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.

Total free memory after linux boot on DM365

Marco Braga
Expert 1780 points

Other Parts Discussed in Thread: TVP7002

Hello,

I'd like to know if it is normal that the linux kernel eats more than 50MB on DM365 EVM. I've booted the board with the supplied kernel (2.6.18), using TFTP. I've used NFS for root, but even booting from jffs2 does not change the numbers. To be sure that nothing is eating up memory, I've specified "init=/bin/sh" to load the shell instead of init and I've specified "mem=80M" at boot. This gives a very minimal environment. The result is this:

sh-3.00# mount -t proc proc /proc/
sh-3.00# free
             total       used       free     shared    buffers     cached
Mem:         76896      52636      24260          0          0       2336
-/+ buffers/cache:      50300      26596

I'd like to be sure that my numbers are ok and that linux really uses 50MB for itself.

Thanks!

 

This is the complete command sequence, if interested:

...

Hit any key to stop autoboot:  0
DM365 EVM :>tftp 0x80700000 uImage-dm365.mv.orig
TFTP from server 192.168.135.250; our IP address is 192.168.135.70
Filename 'uImage-dm365.mv.orig'.
Load address: 0x80700000
Loading: T T #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###########
done
Bytes transferred = 2049992 (1f47c8 hex)
DM365 EVM :>setenv bootargs bootargs 'mem=80M console=ttyS0,115200n8 noinitrd rw ip=192.168.135.70 root=/dev/nfs nfsroot=192.168.135.253:/home/marco/workdir/filesys.mv,nolock video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K dm365_imp.oper_mode=1 davinci_capture.device_type=4 davinci_enc_mngr.ch0_mode=pal init=/bin/sh'
DM365 EVM :>bootm
## Booting kernel from Legacy Image at 80700000 ...
   Image Name:   Linux-2.6.18_pro500-davinci_evm-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2049928 Bytes =  2 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux......................................................................................................................................... done, booting the kernel.
Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le (a0850430@gtlnxlsf01.gt.design.ti.com) (gcc version 4.2.0 20070126 (prerelease) (MontaVista 4.2.0-3.0.0.0702771 2007-03-10)) #1 PREEMPT Fri May 22 12:07:46 EDT 2009
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Machine: DaVinci DM365 EVM
Memory policy: ECC disabled, Data cache writeback
DaVinci DM0365 variant 0x0
PLL0: fixedrate: 24000000, commonrate: 121500000, vpssrate: 243000000
PLL0: vencrate_sd: 27000000, ddrrate: 243000000 mmcsdrate: 121500000
PLL1: armrate: 297000000, voicerate: 20482758, vencrate_hd: 74250000
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
Built 1 zonelists.  Total pages: 20480
Kernel command line: bootargs mem=80M console=ttyS0,115200n8 noinitrd rw ip=192.168.135.70 root=/dev/nfs nfsroot=192.168.135.253:/home/marco/workdir/filesys.mv,nolock video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K dm365_imp.oper_mode=1 davinci_capture.device_type=4 davinci_enc_mngr.ch0_mode=pal init=/bin/sh
PID hash table entries: 512 (order: 9, 2048 bytes)
Clock event device timer0_0 configured with caps set: 07
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 80MB = 80MB total
Memory: 76672KB available (3529K code, 712K data, 204K init)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
MUX: initialized SPI0_SCLK
MUX: initialized SPI0_SDO)
MUX: initialized SPI0_SDI
MUX: initialized SPI0_SDENA0
DaVinci: 104 gpio irqs
MUX: initialized GPIO20
MUX: initialized I2C_SCL
DM365 IPIPE initialized in Single Shot mode
Generic PHY: Registered new driver
ch0 default output "COMPOSITE", mode "PAL"
VPBE Encoder Initialized
LogicPD encoder initialized
Avnetlcd encoder initialized
dm365_afew_hw_init
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
squashfs: version 3.1 (2006/08/19) Phillip Lougher
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
yaffs May 22 2009 12:04:06 Installing.
SGI XFS with no debug enabled
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
davincifb davincifb.0: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 4050KB
davincifb davincifb.0: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 1224KB
davincifb davincifb.0: dm_osd1_fb: 720x576x4@0,0 with framebuffer size 810KB
davincifb davincifb.0: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 1224KB
DAVINCI-WDT: DaVinci Watchdog Timer: heartbeat 60 sec
facedetect major#: 253, minor# 0
facedetect driver registered
imp serializer initialized
davinci_previewer initialized
davinci_resizer initialized
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO map 0x1c20000 mem 0xfbc20000 (irq = 40) is a 16550A
serial8250.0: ttyS1 at MMIO map 0x1d06000 mem 0xfbd06000 (irq = 41) is a 16550A
RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize
Davinci EMAC MII Bus: probed
MAC address is 00:0e:99:02:c9:35
TI DaVinci EMAC Linux version updated 4.0
netconsole: not configured, aborting
Linux video capture interface: v2.00
vpfe_init
starting ccdc_reset...<7>
End of ccdc_reset...<5>vpfe_probe
vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = MT9T001
vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = MT9P031
TVP514X : nummber of channels = 1
vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = TVP514X
Trying to register davinci display video device.
layer=c07f5600,layer->video_dev=c07f5760
Trying to register davinci display video device.
layer=c07f5400,layer->video_dev=c07f5560
davinci_init:DaVinci V4L2 Display Driver V1.0 loaded
vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = TVP7002
af major#: 250, minor# 0
AF Driver initialized
aew major#: 249, minor# 0
AEW Driver initialized
i2c /dev entries driver
nand_davinci nand_davinci.0: Using 4-bit hardware ECC
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)
2 NAND chips detected
Creating 5 MTD partitions on "nand_davinci.0":
0x00000000-0x003c0000 : "bootloader"
0x003c0000-0x00400000 : "params"
0x00400000-0x00800000 : "kernel"
0x00800000-0x20800000 : "filesystem1"
0x20800000-0x80000000 : "filesystem2"
nand_davinci nand_davinci.0: hardware revision: 2.3
dm_spi.0: davinci SPI Controller driver at 0xc581e000 (irq = 42) use_dma=0
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
musb_hdrc: version 6.0, cppi-dma, host, debug=0
MUX: initialized GPIO33
musb_hdrc musb_hdrc: No DMA interrupt line
musb_hdrc: USB Host mode controller at c5874000 using DMA, IRQ 12
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
mice: PS/2 mouse device common for all mice
davinci-mmc davinci-mmc.0: Supporting 4-bit mode
davinci-mmc davinci-mmc.0: Using DMA mode
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
ASoC version 0.13.1
AIC3X Audio Codec 0.2
asoc: aic3x <-> davinci-i2s mapping ok
ALSA device list:
  #0: DaVinci DM365 EVM (aic3x)
IPv4 over IPv4 tunneling driver
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Time: timer0_1 clocksource has been installed.
Clock event device timer0_0 configured with caps set: 08
Switched to high resolution mode on CPU 0
usb 1-1: new high speed USB device using musb_hdrc and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
      device=eth0, addr=192.168.135.70, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.135.70, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=192.168.135.253, rootpath=
Looking up port of RPC 100003/2 on 192.168.135.253
Looking up port of RPC 100005/1 on 192.168.135.253
VFS: Mounted root (nfs filesystem).
Freeing init memory: 204K
sh-3.00# free
sh-3.00# mount -t proc proc /proc/
sh-3.00# free
             total       used       free     shared    buffers     cached
Mem:         76896      52636      24260          0          0       2336
-/+ buffers/cache:      50300      26596
Swap:            0          0          0
sh-3.00#

  • 0
    Expert 1505 points

    I'm concerning this issue too.

    Who can help on this?

  • 0 in reply to Tracy lee
    TI__Mastermind 19985 points

    Hi,

    I have not analyzed the complete breakup of the kernel memory requirement, but i know a few things which surely add around 20MB of memory usage inside the kernel.

    1. If you refer to davinci_vpfe.c, there is a static allocation of buffers of size around 4.6MB each with the number of buffers equal to 3 or 5 based on your settings of the kernel source. This itself uses up nearly 14-20MB of the memory. This memory is used for MMAP capture buffers for V4L2 layer. This memory is statically allocated as soon as the driver is installed during bootup.

    2. Similar to above, there are buffers for display that are allocated based on your bootargs. If you dont need any display device, you can turn off your display bootargs and then free up the memory.

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    Expert 1505 points

    Hi Anshuman:

         Could we just remove the memory allocate if we use "V4L2_MEMORY_USERPTR" mode? It would we appreciate if you can provide the  update code for reference if we don't want use "V4L2_MEMORY_MMAP" mode?

         BTW, when we use "V4L2_MEMORY_MMAP" mode, I think the driver should not allocate the memory when the driver was installed during bootup, the driver should allocate the buffer when call "VIDIOC_REQBUFS" commands, just my 2 cents, how do you think about it?

         Thanks.

  • 0 in reply to Tracy lee
    TI__Mastermind 19985 points

    Hi Tracy,

    I agree with your points. Basically, the driver is not allocating the memory run-time using kmalloc. It is doing static allocation from kernel heap.

    If you are sure that in your system you will use USERPTR buffers, then you can reduce the display or capture buffer sizes in kernel drivers to minimal and also change number of buffers to say 0 or 1.

    For the changes you suggested, i think they are long term changes and are present due to legacy reasons also.

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    Expert 1505 points

    Hi Anshuman:

          I had tryed change the number of buffers to 0 for capture driver and use USERPTR buffers for up layer, I can't get image from driver after change the parameters in driver, could you help check this?

          When we change the number of buffers to 0, we will found that the free memory will increase about 25M after camera boot up,  origiral settings is support 1080I UYVY + VGA UYVY, and
                   (1920*1080*2) + (640*480*2) = 14,284,800 Bytes

          That means the driver allocate extra 10M for other use, maybe for previewer or resizer driver, Could you help explain this?

          Thanks.

  • 0 in reply to Tracy lee
    TI__Mastermind 19985 points

    Tracy,

    I have to look at the driver code but it will take some time. Ideally, it should have worked with turning the number of buffers to 0. Meanwhile, can you please reduce the size of each buffer and still keep the number of buffers to, say 3.

    BTW, what is the problem you face when you change the number of buffers to 0? What do you mean by "I can't get image from driver"?

     

    Regards,

    Anshuman

  • 0 in reply to Tracy lee
    Expert 1780 points

    Hi,

    since I have originally brought up the problem, I am still interested in this point. While I agree that a complete support for all v4l methods is important, practical issues are even more important when developing a real product. I think that USERPTR is the best and most used method of exchanging video buffers so limiting to this method and gaining several MBs of memory is a good thing. Sadly I am not really experienced with v4l and in particular USERPTRs but if there is anything I can to to help let me know.

     

     

  • 0 in reply to Anshuman Saxena
    Expert 1505 points

    Hi Anshuman:

    Anshuman Saxena said:

    I have to look at the driver code but it will take some time. Ideally, it should have worked with turning the number of buffers to 0. Meanwhile, can you please reduce the size of each buffer and still keep the number of buffers to, say 3.

    BTW, what is the problem you face when you change the number of buffers to 0? What do you mean by "I can't get image from driver"?

    When I change the number of the buffers to 0, the raw data from capture driver will be wrong, the image is not incorrect, here is an example for you reference:

  • 0 in reply to Tracy lee
    Expert 1780 points

    Pardon my ignorance, but I think video capture uses DMA to transfer actual pixel data from the video port to somewhere in memory. Even if only buffer pointers are exchanged, the buffers required to contain actual video data must be stored somewhere. Can the driver really work without any buffer? Or there are different buffers used for actual video data capture and a separate set of buffer for exchange between user mode/kernel mode?

     

  • 0 in reply to Tracy lee
    TI__Mastermind 19985 points

    Hi Tracy,

    I dont understand, why this should happen. You are using USERPTR buffers and just change the number of buffers in davinci_vpfe.c to 3 gives you correct output whereas setting number of buffers to 0 gives wrong output? Isnt it?

    Did you try reducing the memory buffer size in davinci_vpfe.c?

    Also, this buffer you captured is just after the VIDIOC_DQBUF IOCTL? Isnt it?

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    Expert 1780 points

    Hello,

    I'm going to summarize what I've understood from this thread and from the linux driver/DMAI source code.

    While investigating on the use of the 2 resizer on dm365 using DMAI, I've seen that one of the requirement is to allocate a video buffer that will contain both resizer outputs. Actually video buffers can be allocated in 2 ways:

    1) Driver allocation: the user does not specify any BufTab when calling Capture_create. The driver allocates memory and V4L2_MEMORY_MMAP method is used. The truth is that there is no real allocation at this point. Buffers have already been allocated by the driver at initialization time. Buffer size/number can be modified when the davinci_capture.ko module is loaded, but once the module is loaded the memory will be used and not available to the system.

    2) User allocation: buffers are allocated by the user application, and used by the buffer. A BufTab must be created in the app and passed to Capture_create. This method uses V4L2_MEMORY_USERPTR, and buffers are actually allocated in CMEM's memory.

    A few things must be noted. If method 1 is used, the system can capture the video even if CMEM driver module is not loaded. Buffer memory has already been allocated by the driver from linux system memory. If method 2 is used, CMEM module parameters must specify an adequate buffer area.

    Ex: capturing 1280x720 UYVY will require 1280*720*2 sized buffers = 1800Kb.

    CMEM load:

    insmod /opt/dsp/cmemk.ko phys_start=0x85000000 phys_end=0x88000000 pools=3x1843200

    The downside is that memory will be wasted, since memory will be taken by CMEM and memory used by linux driver (already allocated) will not be used. BUT the video capture driver can be loaded with 0 buffers. This will limit memory allocation to CMEM:

    modprobe davinci_capture channel0_numbuffers=0

    At this point, V4L2_MEMORY_MMAP will not work anymore. But no system memory will be used by the linux video capture driver. The amount of memory allocated by the linux video capture driver has a default: 1920*1080*2 + 640*480*2 = 4650Kb for each buffer. Since 3 buffers are allocated, this is a total of 13MB.

    So:

    1) If you are going to alloc BufTabs yourself, check CMEM and turn off driver memory allocation.

    2) If you are going to use driver allocation, there is no need to increase the buffer size (as I've seen in a thread on dm365 resizer) since the buffers will already be full sized.

     

  • 0 in reply to Marco Braga
    TI__Mastermind 19985 points

    Marco,

    Your summary is correct. Thanks for putting together such a detailed report.

    Regards,

    Anshuman

    PS: Please mark this post as verified if you think it answers your question.

  • 0 in reply to Marco Braga
    Expert 2315 points

    Hi Marco,

    is there any performance issues using the driver allocaed memory or the "user pointer" memory in an application.  I am using fbdev_loopback demo where driver buffers are used and I am trying to find out where I can make improvements as I am struggling to get my video buffers "synchronised" properly at a specific point in time at the end of initialisation of my program before jumping into a loop that gets capture buffer from the queue, manipulate it a bit and pass it to the display.  The manipulation involves taking data from a ringbuffer that rceives from ethernet UDP data which is sent in sync with the camera but the buffering in the driver seems to "skip" a frame now and then, like about 5% of the time between startups but when the app is running the delay is fixed which is OK but the startup sync is giving me nightmares.  Would it help doing my app in a kernel module to avoid user-space in this instancE?

    Thanks, Jinh T.

  • 0 in reply to Jinh
    Mastermind 6805 points

    Marco or Anshuman or anyone else:

    I've been getting a dma_alloc_coherent failure (size 4149248) when trying to get the canny edge detector example working on my DM6467T EVM.  I've been pulling my hair out for days and can't figure it out.  In fact, I don't even know if the code should even be trying to do this allocate.  I *believe* I've isolated the problem to come from a call to Capture_create, and a forum search led me to your post.

    Your statements seem germane, but I'm not sure.  Could you PLEASE look at one or more of my other posts on the subject, and see if you have any insight for me?

    http://e2e.ti.com/support/embedded/f/354/p/89419/310162.aspx#310162

    http://e2e.ti.com/support/embedded/f/354/p/89319/309645.aspx#309645

    Thanks very much,

    Helmut

  • 0
    Intellectual 545 points

    hi marco,

     

    ya usally the kernal will use memory upto 60MB.........its normal u can go ahead...