TI DM8148 EZSDK software organization

From DAVE Developer's Wiki
Revision as of 07:51, 21 August 2015 by DevWikiAdmin (talk | contribs) (Introduction)

(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Info Box
Naon am387x-dm814x.png Applies to Naon
Maya 03.png Applies to Maya
Dido-main.png Applies to Dido

Introduction[edit | edit source]

DM8148 digital media processor implements a multi-processor architecture. As such, software architecture is quite complex with respect to the typical single-processor embedded linux system.

The following picture shows a simplified block diagram of this software architecture.

DM8148 simplified software architecture (EZSDK)

Three different software domains are visible (*):

  1. the first one runs on the ARM Cortex-A8 processor; this is a usual embedded linux system
  2. the second one runs on two ARM Cortex-M3 processors, called Media controllers according to Texas Instruments nomenclature; this is based on SYS/BIOS RTOS (http://processors.wiki.ti.com/index.php/Category:SYSBIOS)
  3. the third one runs on DSP; no default implementation is provided.

ARM Cortex-A8 is the main processor that drives - for example - the boot process of the entire chip. From the initialization standpoint, media controllers and DSP are slave with respect to Cortex-A8. This means that media controllers' and DSP's firmwares need to be loaded by Cortex-A8.

A fundamental role is played by memory layout definition. For more details please refer to Memory_organization_(Naon)#RAM_Memory_Map.

(*) Actually a fourth domain - running on the two ARM9s integrated in codec block - exists. Since this piece of software is not accessible at all, this block needs to be considered as a hardware black box.

SysLink[edit | edit source]

SysLink can be considered as a sort of "glue logic" that allows all these different processors to communicate each other. More information about SysLink can be found here: http://processors.wiki.ti.com/index.php/Category:SysLink.

Cortex-M3 (Media controllers) - SYS/BIOS[edit | edit source]

Two media controllers are integrated. They perform two basic functions:

  • controlling HDVPSS and HDVICP2 blocks (one for each media controller)
  • exposing a software interface to Cortex-A8 domain in order to allow access to HDVPSS and HDVICP2 resources; this interface is composed by two parts:
    • OpenMAX
    • FVID2.

Please note that media controllers - even if are basically conceived to deal with HDVPSS and HDVICP2 management - are able to access directly all the hardware blocks - through System Interconnect http://www.ti.com/lit/ds/symlink/tms320dm8148.pdf - that are integrated in DM8148 (e.g. I2C controllers or Ethernet switch).

Cortex-A8 - Linux[edit | edit source]

As mentioned previously, Cortex-A8 is the main processor of DM8148 platform. As such it controls the boot sequence during which it runs:

  1. bootrom
  2. u-boot
  3. linux kernel and applications.

From the linux standpoint, usual device drivers interact directly with hardware level in order to control peripherals (I2C controllers, ethernet switch, SATA controller, audio ports etc.). This is not true for video processing subsystem - composed by HDVPSS and HDVICP2 - that can be accessed through two software interfaces, OpenMAX and FVID2.

As shown in the picture, the communication with FVID2 interface is implemented on Linux domain side at device drivers level. For example V4L2 implementation provided by EZSDK adopts this approach (for more details please refer to http://processors.wiki.ti.com/index.php/DM814x_AM387x_PSP_04.01.00.06_V4L2_Capture_Release_Notes).

OpenMAX implementation lives on user space instead. It interfaces its counterpart running on media controller domain. Please note that implementation provided by TI EZSDK referes to OpenMAX IL layer. Applications - called OpenMAX clients - or media frameworks - such as gstreamer - sit on top of this layer.

DSP[edit | edit source]

As mentioned above, no default implementation is provided because developers are totally free to use DSP as they wish. Several approaches are available. For example DSP could run multi-tasking applicaiton code on top of SYS/BIOS RTOS or it could run classical "while(1)" single-task program.

Some examples are provided by EZSDK:

Please note that DSP is able to access all the hardware blocks (through System Interconnect) that are integrated on-chip like I2C controllers or Ethernet switch.