zero copy architecture in RDK of TI 8168 EVM

原创 2012年03月20日 16:59:41
1 the RDK overview:

    Work is based on EVM: 8168SoC + 5158VideoCapture + 1GB DDR2.

    RDK is an open source SDK which enable you to modify and rebuild uboot, kernel, vpss package, dsp/m3 program, and the core concepts in it are links and mcfw(multichannel framework).  A link is a software entity running on a core with input queue and output queue, also with a unique ID to let other link and the system find it. You can consider a link as a basic component in the software architecture, so links could be placed in different order or topology to change the system behavior.  Links could be connected to each other by specifying a link's previous link and related queue number. For eg, link A could be connect to link B by setting link B's previous ID to A and queue number to 0. mcfw is built based on links which using predefined link topology resulting much easier configuration for the whole system. A link contains its own thread to process data and handling control commands.

                            Capture
                                  |                                                                  
                                 DEI
                                  |
                                  NF
                                  |
                                 DUP
                                 | |
        ------------------------------------------
        |                                                   |                                                      
     SW Mosaic                              IPC OUT (M3)
     (SC5 422)                                      |
        |                                              IPC IN  (M3)
        |                                                   |
    On-Chip HDMI                         Encode
      1080p60                                        |
                                                IPC BITS OUT (M3)
                                                            |
                                                 IPC BITS IN  (A8)

           graphic 1. links example

    The graphic 1 shows a system containing several links to work as capture->display and encode. It is a combination of links. Changing the link order could make a custom usecase.


2 how link works

    When a link is setup correctly and started, it would automatically pull data from previous link and push the processed data to next link. Because each core have links on it, there needs to be a way to transfer messages between them, this is called IPC(inter processor communication), which enables ARM working with DSP and M3 cores.


      graph 2: Link overview

    As the graphic says, links is built upon traditional software components used on TI Davince serials, syslink. Links resides on different cores so they need syslink/IPC to provide communication across different OS and cores. Syslink use shared memory which different core can access to transfer messages. Some uncached shared memory was used to format a message queue infrastructure, Some are used as heap from which big frame buffer could be allocated.



3 memory layout to make link work
     The physical memory on EVM board is divided to several sections, by default 1GB EVM is divided as following:

(Unrelated sections were not listed here, SR = Shared Region.)
#  0x8000 0000, 256MB, Linux on ARM
#  0x9000 0000, 87MB, SR1, used for transfer bit stream between ARM and M3 video subsystem(codec and decodec).
#  0x9570 0000, 1MB, SR2, used for IPC M3 List MP.(Cached)
#  0xA800 0000, 361MB, SR3, used for frame buffers.
#  0xBE90 0000, 16MB, SR0, used for message queue and IPC List MP.(Uncached)

(Note: DSP and ARM core have its own MMU, but for DDR they are seeing the same physical address)


    The communication is designed to transfer message encapsulated in message queue, which can also called mailbox. If ARM want to send a command to M3 or DSP, ARM need to encapsulate the information into a message and copy it to the SR0(Note, mailbox and lock is actually implemented with hardware support, the chip have 12 "mailboxes" with related interrupts and register, the chip also have 64 hardware "spinlocks" and related register). Frame buffers are organized into lists which resides in SR0  and SR2, while frame buffers resides in SR3, and bit stream from codec resides in SR1. SR2 is cached So it was only used between cores which have same type, in 8168 they are M3 cores.
     The section divided here does not means hardware and firmware banned a core accessing the sections not belonging to them, but if it did there is risk to break the system. I have not try to change the memory layout, but it is possible by modifying uboot, kernel, and VPSS address mapping. On ARM you can access the shared region which was belonging to DSP and M3, But simply mmap() would give you a wrong virtual address. Another thing it refers  is: message queue used SR0 which is uncached and only have 16MB, So do not put large data in the message. If you want to transfer a large set of data, allocated it in other region and encapsulate a pointer pointering to the allocated buffer into the message queue. Following is a demonstration that a link(not a codec link) used to tell other link on another different core that it have new data.


                              graphic 3 example to transfer frames between links

    There are 3 pairs of data and code sections reserved for M3 VPSS, M3 Video, DSP, they are private for each core. What a user need to take care is that, the data section is 2MB, and data section is 10MB/12MB, so it suits for algorithm not memory scan likewise application.



4 Zero copy for frames
    The framework allocate all frame buffers in SR3, and chains the pointer to it into a list. So what changes and transferred are only list and messages, the frame buffer were never copied except "duplication link". One frame is hold and accessed only by one link at one time.

基于TI 8168 RDK 4.0 多路解码

总的流程 如下: 读文件代码: static Void *readRevframeThr(Void * prm){ static UInt32 flag =0; static UInt...
  • liqinghan
  • liqinghan
  • 2015-07-21 15:23:42
  • 1581

DM8168 DVRRDK DSP算法开发(OSD)

1 系统编译 ① Linux端(A8)编译命令: make –s dvr_rdk_linux 在文件夹 DVRRDK_04.01.00.02/dvr_rdk/bin/ti816x/bin/ 生成 ...
  • wu20093346
  • wu20093346
  • 2016-01-04 10:22:47
  • 2471

TI8168 DSP算法开发流程

一、DM8168及本文简介     2010年,TI推出的最新媒体处理器TMS320DM8168作为一款多通道高清SOC系统芯片,集成了1GHz主频Cortex-A8 ARM核与lGHz主频C6...
  • jiawenquan
  • jiawenquan
  • 2014-03-05 10:18:53
  • 4131

TI DM8168 MCFW

转载 来源: http://blog.csdn.net/yyplc/article/details/12040999 图像算法集成基于TI Davinci DM8168,开发平台SDK为...
  • keepingstudying
  • keepingstudying
  • 2016-03-14 14:26:45
  • 1441

DM8168 & DVR_RDK配置

从14年8月接触板子,开始学习达芬奇DM8168的架构并尝试移植项目的代码到板子上运行。到15年4月共8个月时间,从板子uboot,打印简单的hello world到把项目代码移植到架构中,调整DSP...
  • Derek_Tian
  • Derek_Tian
  • 2015-04-27 20:25:57
  • 1400

IPNC开发笔记——关于IPNC_RDK_4.1.0的分析

一、在IPNC_RDK_4.1.0中的开发包,主要分两大部分:dvsdk_ipnctools、ipnc_appipnc_rdk; dvsdk_ipnctools是ti官方提供的各种ipnc开...
  • pugu12
  • pugu12
  • 2015-12-29 10:01:43
  • 1281

components and building system in RDK for TI 8168

DSP:     one pre-built static library: SCD algorithm.     one algorithm with source files: SWOSD...
  • xiaxia347
  • xiaxia347
  • 2012-03-20 19:45:25
  • 570

TI DVRRDK4.0 设置背景地图的方法1

TI DVRRDK4.0 设置背景地图的方法1 TI DVRRDK4.0 设置背景地图的方法1 1、在swmsLink中修改,由于swmsLink是属于vpss M3核,而我想要的是通过A8的程序去控...
  • liqinghan
  • liqinghan
  • 2015-07-17 14:51:37
  • 1032

UserGuide_IPNC_RDK_DM36x V5.1

  • 2014年05月16日 10:18
  • 5.69MB
  • 下载

DM8168达芬奇视频 SoC(TI)

日前,德州仪器 (TI) 宣布推出全新 TMS320DM8168 达芬奇 (DaVinci™) 视频片上系统 (SoC),将高清多通道系统的所有捕获、压缩、显示以及控制功能完美整合于单芯片之上,从而不...
  • keepingstudying
  • keepingstudying
  • 2014-07-25 09:13:00
  • 1065
收藏助手
不良信息举报
您举报文章:zero copy architecture in RDK of TI 8168 EVM
举报原因:
原因补充:

(最多只允许输入30个字)