Re-planning BEAGLEBOARD-XM memory allocation

Recently doing a thing that requires a large image to be JPEG compressed. BEAGLEBOARD-XM The default allocation of memory to the CMEM and DSP end Heap is not sufficient, and memory blocks need to be redistributed. Looked at the script for the memory allocation in the startup script and codec server, and quickly found the place to change.

1, the first need to modify is the startup parameters

The original startup parameters are:

CONSOLE=TTYS2,115200N8 noinitrd RW Ip=192.168.10.101:192.168.10.100:192.168.10.1:255.255.255.0::usb0:off root=/dev /nfs nfsroot=192.168.10.100:/home/ubuntu/install/dm3730/targetfs,nolock,rsize=1024,wsize=1024mem=55m@0x80000000 mpurate=1000 omap_vout.vid1_static_vrfb_alloc=y omapfb.vram=0:8mmem=384m@0x88000000 omapfb.mode=dvi:hd720 Omapdss.def_disp=dvi vram=8m rootwait camera=lbcm5m03

Where mem=384@0x88000000 should be assigned to the video card, Omapfb.vram should be video memory bar. Oh, I didn't read the document, I'm not sure. Anyway, I'm going to keep an eye on this piece of memory. 128M From here, modify the startup parameters to:

' Console=ttys2,115200n8 noinitrd rw ip=192.168.10.101:192.168.10.100:192.168.10.1:255.255.255.0::usb0:off root=/ Dev/nfs nfsroot=192.168.10.100:/home/ubuntu/install/dm3730/targetfs,nolock,rsize=1024,wsize=1024mem= 55m@0x80000000 mpurate=1000 omap_vout.vid1_static_vrfb_alloc=y omapfb.vram=0:8mmem=256m@0x90000000 Omapfb.mode=dvi : hd720 omapdss.def_disp=dvi vram=8m rootwait camera=lbcm5m03 '

2. Then modify the Cmem memory allocation

To find/ETC/INIT.D/LOADMODULE-RC in the embedded file system, you can see a comment like this:

# Default Memory Map for DM3730 EVM
#
# Start Addr Size Description
# -------------------------------------------
# 0x80000000 MB Linux
# 0x83700000 MB Cmem
# 0x85900000-MB CODEC SERVER

This is the default memory allocation situation, the 0x80000000 starting 55MB corresponding to the starting parameter mem=55m@0x80000000,0x85900000 39MB is left to the DSP program, divided to Cmem is 0x83700000 the beginning of 34MB. The specific assignment is performed by this command: modprobe cmemk phys_start=0x83700000 phys_end=0x85900000 allowoverlap=1 useheapifpoolunavailable=1

Did you just exploit 128M of memory space from the video? Now half of it to CMEM management, that is, the size of the CMEM is 34+64=98MB, the starting address is not changed, or 0x83700000, and the termination address to fix 0x89900000, the script in the statement modified to Modprobe CMEMK Phys_ start=0x83700000 phys_end=0x89900000 allowoverlap=1 useheapifpoolunavailable=1

3, the most later modified codec server is the DSP side of the program memory allocation.

Just now, the original script assigns the 39MB of the 0x85900000 start to the DSP. Say is "allocation", in fact, in arm and Linux at one end do not need any action, who do not use this piece of memory, left to the DSP to enjoy the line. But on the DSP side can not be Shang, must be configured, in the codec server's. tcf file, according to the current memory division to reallocate memory. This TCF file, is the single-core DSP era Dsp/bios configuration file, the year under the ccs3.3 has a graphical configuration tool to operate. Now get into the Linux under, degenerate into the need to manually edit the script, hehe. In fact, can also be graphical configuration, need to pay to buy CCS5 for Linux version of license, shining white of silver ah ...

My TCF here does not directly write memory allocations, but rather contains a memmap.tci, similar to. c contains. h, and memory is allocated in this area. It doesn't matter where you are, just make it right. The algorithm handles large images and requires large heap, then throws the remaining 64M memory into the heap. That is, there are two things to modify, one is the starting address of the DSP program, reaching, this address has changed, each memory block of the starting address must be changed, and then one is the heap size, find the heap of memory block, the 64M thrown in the OK. 1, 2, 3 after the modification, the first to recompile codec server, and then recompile the application called codec server, all compiled through, with the new startup parameters to start the kernel, the codec server and the application of both the goods are copied to the file system, The operation is OK.