The Z3 codebase assumes that certain modules are installed in the Linux system. To install all the modules needed by Z3, type the following command in Ubuntu/Debian:

    sudo apt-get install bison flex mtd-utils liblzo2-dev uuid-dev zlib1g-dev libpcre3-dev autoconf \
         autoconf-archive automake automake1.9 libtool libtool-doc lynx xutils-dev

In Fedora you would type:

   sudo yum install bison flex mtd-utils mtd-utils-ubi lzo-devel libuuid-devel pcre-devel automake \
        automake17 automake14 autoconf libtool lynx xorg-x11-server-devel

Yes, but it is necessary to retrieve some 32-bit libraries that are used in the Z3 codebase. In Ubuntu, you can get these modules by typing:

   sudo dpkg --add-architecture i386
   sudo apt-get update
   sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 zlib1g:i386

In Fedora, you would type:

    sudo yum install glibc.i686

The Z3 codebase can be built on Ubuntu 10.x or later. Most versions of Fedora should also work.

This can be solved by installing the modules described in Question (1).

The error message looks something like this:

libtool: compile:  arm_v5t_le-gcc -DHAVE_CONFIG_H -DHAVE_VERSION_H -DLIBRARY_DIR=\"/opt/webgui/lighttpd/lib\" 
-DSBIN_DIR=\"/opt/webgui/lighttpd/sbin\" -I. -I.. -D_REENTRANT -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -D_LARGE_FILES -g -O2 -Wall -W -Wshadow -pedantic -std=gnu99 -MT mod_flv_streaming.lo -MD -MP 
-MF .deps/mod_flv_streaming.Tpo -c mod_flv_streaming.c  -fPIC -DPIC 
-o .libs/mod_flv_streaming.o In file included from base.h:24,
                 from mod_flv_streaming.c:1:
array.h:9:19: error: pcre.h: No such file or directory In file included from base.h:24,
                 from mod_flv_streaming.c:1:
array.h:130: error: expected specifier-qualifier-list before 'pcre'
In file included from base.h:26,
                 from mod_flv_streaming.c:1:
keyvalue.h:56: error: expected specifier-qualifier-list before 'pcre'
keyvalue.h:61: warning: struct has no members
make[5]: *** [mod_flv_streaming.lo] Error 1
make[4]: *** [all] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [lighttpd] Error 2
make[1]: Leaving directory `/home/z3/z3-dm814x/z3-centaurus-dm814x_RPS-20130829/sysapps'
make: *** [sysapps] Error 2

The first potential cause of this is not having the automake tools installed. You should make sure the command described in Question (1) was run.

If it was, this could also be an indicator that a “make clean” is needed. Try typing “make clean” and then try typing “./makeall.sh”.

The error message looks something like this:

*

* System Logging Utilities

*

syslogd (SYSLOGD) [Y/n/?] y

  Rotate message files (FEATURE_ROTATE_LOGFILE) [Y/n/?] y

  Remote Log support (FEATURE_REMOTE_LOG) [Y/n/?] y

  Support -D (drop dups) option (FEATURE_SYSLOGD_DUP) [Y/n/?] y

  Circular Buffer support (FEATURE_IPC_SYSLOG) [Y/n/?] y

    Circular buffer size in Kbytes (minimum 4KB) (FEATURE_IPC_SYSLOG_BUFFER_SIZE) [128] 128

    logread (LOGREAD) [Y/n/?] y

      Double buffering (FEATURE_LOGREAD_REDUCED_LOCKING) [Y/n/?] y

klogd (KLOGD) [Y/n/?] y

logger (LOGGER) [Y/n/?] y

etc/config.c:8: error: 'UTS_RELEASE' undeclared here (not in a function)

This is due to bison not being installed. Running the command described in Question (1) will address this.

The error message looks something like this:

/home/z3/z3-dm814x/z3-centaurus-dm814x_RPS-20130829/ezsdk/component-sources/omx_05_02_00_38/bin/maketemp_configuro_cmd_c6xdsp.bat: -e: not found

make[3]: *** [xdc_configuro] Error 127

make[2]: *** [dm81xxdspXdc] Error 2

make[1]: *** [omx] Error 2

make: *** [ezsdk] Error 2

The problem is that /bin/sh is not linked to bash. The fix on Ubuntu is to run:

    sudo dpkg-reconfigure dash

and then select “No” when it asks if “dash” should be the system shell (this will cause /bin/sh to be linked to “bash” instead).

This is an indicator that the host gcc is being used to build the code rather than Z3's cross-compiler. Compiling should be done with the following commands (here giodebug.c is the file to be compiled):

    source z3-env
    ${CROSS_COMPILE}gcc  -o giodebug -DUNIT_TEST giodebug.c

Then when you run

    file giodebug

it should report:

    giodebug: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

The full erorr message looks like:

make -fMAKEFILE.MK libs TARGET=clean
make[4]: Entering directory `/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk/dvr_rdk/mcfw/src_linux'
make -fMAKEFILE.MK -C/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk/dvr_rdk/../dvr_rdk/mcfw/src_linux/osa/src MODULE=dvr_rdk_osa clean
make[5]: Entering directory `/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk/dvr_rdk/mcfw/src_linux/osa/src'
make[5]: echo: Command not found
make[5]: *** [clean] Error 127
make[5]: Leaving directory `/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk/dvr_rdk/mcfw/src_linux/osa/src'
make[4]: *** [osa] Error 2
make[4]: Leaving directory `/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk/dvr_rdk/mcfw/src_linux'
make[3]: *** [clean] Error 2
make[3]: Leaving directory `/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk/dvr_rdk/mcfw/src_linux'
make[2]: *** [dvr_rdk_linux_clean] Error 2
make[2]: Leaving directory `/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk/dvr_rdk'
make[1]: *** [clean] Error 2
make[1]: Leaving directory `/home/z3/z3-netra-rdk/z3-netra-RDK-20130513/dvr-rdk'
make: *** [clean] Error 2
root@nguser-VirtualBox:/home/z3/z3-netra-rdk/z3-netra-RDK-20130513#

This occurred for a customer using Ubuntu 10.4 LTS. They resolved this issue by updating their environment. We recommend you try the same.

Hold down the space bar and power on the unit. Keep pressing space bar as power comes up. This should cause a stop in u-boot.

Hold down the “s” key and power on the unit. Keep holding the “s” key. This will cause a stop at the Z3-MIN prompt.

You can reprogram the module using BOOTP. This process involves setting up a BOOTP server on your development PC, setting some jumpers on your module, connecting the module to your development PC via the Ethernet, and then turning on the board. Detailed procedures on doing this for DM8107 modules can be found here. Details on doing this for DM8148 modules can be found here. Details on doing this for DM8168 modules can be found here. For details on doing this on other platforms, please contact Z3.

There are various reasons this can occur. A good place to start is to make sure that TFTP is working properly. Question (1) in the TFTP sections lists multiple things to check to make sure TFTP is working as expected.

One of the most common reasons BOOTP doesn't work is the need for a “-s” in the server_args settings in the tftp config file. In the file /etc/xinetd.d/tftp, you should make sure that the “/home” argument in “server_args” is preceded by a “-s”. An example of a valid tftp file is shown below:

    service tftp
    {
       disable     = no
       socket_type = dgram
       protocol    = udp
       wait        = yes
       user        = nobody
       server      = /usr/sbin/in.tftpd
       server_args = -s /home
    }

Once this change is made, be sure to restart TFTP so this change can take effect.

This is currently not supported.

In the 810x: 4.04.00.01

In the 814x: 4.01.00.05

In the 816x: 4.00.00.09

For DM368 u-boot versions, please contact Z3 Technology.

This can happen if you are in the process of changing between the EZSDK and RDK but only part of the system got updated. Please be sure to use the Updater in the Web GUI when doing this update. More details can also be found in the manual “Updating from the EZSDK to the RDK.”

The full message is:

    BusyBox v1.15.0.svn (2013-07-18 12:30:30 CEST) built-in shell (ash) 
    Enter 'help' for a list of built-in commands. 

    Memory: CMEM 128M , Linux 128M, Total 256M 
    Changed clock rate from 72000000 to 72000000 
    davinci_platform: No internal HD clock available, use external. 
    Preloading gstreamer components 

    (gst-inspect-0.10:697): GStreamer-WARNING **: Failed to load plugin '/opt/gstreamer/lib/gstreamer-0.10/libgstmad.so': /opt/gstreame/lib/libid3tag.so.0: undefined symbol: id3_frametype_obsolete 

This is caused by building the image without the 'gperf' package. To fix this, install gperf and rebuild. On Ubuntu/Debian you can type:

    sudo apt-get install gperf

On Fedora you would type:

    sudo yum install gperf

There is a known bug in older EZSDK/RDK releases involving the file /etc/volatile.cache. Check to see if it has a file size of 0. If it does, do the following steps:

    rm /etc/volatile.cache
    sync
    reboot -f

Note – newer EZSDK/RDK releases (after September/2013) have a fix for this issue.

Yes, this is possible on DM81xx systems. For RDK-based systems the procedure is as follows:

(1) Take a USB drive (must be FAT32 format)

(2) Remove any .img files that exist in the root directory of that USB drive

• Having other .img files in the root directory might cause the wrong .img file to be updated.

(3) Copy the .img file *as-is* to the USB drive root directory

• It is important not to rename it (note that this is different from the EZSDK procedure, which requires renaming).

(4) Plug the USB drive into the board and boot the board. You should see something like the following at the beginning of u-boot:

U-Boot 2010.06-dirty (Jul 16 2014 - 21:51:40)

DM385-GP rev 1.0

ARM clk: 1000MHz
DDR clk: 533MHz
L3 clk: 240MHz
IVA clk: 480MHz
ISS clk: 560MHz
DSS clk: 240MHz
DSP clk: 750MHz

I2C:   ready
DRAM:  1 GiB
NAND:  setting chip delay to 15us
HW ECC BCH8 Selected
256 MiB
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@                                                                           @@
@@                                                                           @@
@@                                                                           @@
@@                                                                           @@
@@      @@@        @.   @.          @@@@     @@    @@@@@@   @@@@@@@@@@@      @@
@@      @@@@@     L@@  @@@         @@@@@i  @@@@   @@    @@           @@      @@
@@      @@ @@@.   @@@  @@@         @,  @@    @@   @@    @@           @@      @@
@@      @@   @@   @@@  @@@         @@;@@:    @@   @@    @@          @@       @@
@@      @@    @@  @@@.l@L@         ,@@@@     @@   @@    @@         @@        @@
@@      @@    @@ l@ @@@@ @.        @@ L@@    @@   @@    @@        @@         @@
@@      @@    @@ @@ @@@@ @@       C@   @@    @@   @@    @@       @@          @@
@@      @@   ,@C @@ @@@  @@       C@   @@    @@   @@    @@      @@           @@
@@      @@@@@@@  @@  @@  @@        @@@@@@    @@   @@    @@     @@            @@
@@       @@@@@   @   @    @         @@@,    @@@@   @@@@@@     @@             @@
@@                                                                           @@
@@                                                                           @@
@@                                                                           @@
@@                                                                           @@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Net:   Ethernet clocking: 0x3
<ethaddr> not set. Reading from E-fuse
Detected MACID:84:7e:40:db:33:34
cpsw
Hit any key to stop autoboot:  0 
Booting from NAND and ubifs...
USB:   .
scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
checking for Z3 software image ...
reading sw-4r7-00245-01_dm8107-gige-20140717-mfr.img
reading software image from: sw-4r7-00245-01_dm8107-gige-20140717-mfr.img ...
reading sw-4r7-00245-01_dm8107-gige-20140717-mfr.img
......................................................................................
......................................................................................
:
:
(continues for many lines)
:
:
......................................................................................
........................
verifying image checksum ...
firmware image detected: DM8107-RDK 2014-07-17
writing firmware, please wait ...
## Executing script at 81000000
Saving Environment to NAND...
Erasing Nand...
Warning: Erase size 0x00002000 smaller than one erase block 0x00020000
         Erasing 0x00020000 instead
Erasing at 0x260000 -- 100% complete.
Writing to Nand... done
firmware has been successfully updated.
resetting ...

There is one important note – we have seen from our experience that not all USB drives are successfully recognized by u-boot. If you see the “reading x.img” message, then you know it is successful. Unsuccessful drives will either hang or will say “checking for Z3 software image” but won’t find anything.

In our tests we successfully used a SanDisk Cruzer Glide 32GB and Kingston Data Traveler.

Note that the Z3-DM816X-PCI2-RPS system comes with with an APP-41 that does not have a USB support, so that software does not support recognizing USB drives in u-boot. If this functionality is needed on a Z3-DM816X-PCI2-RPS release please contact Z3 Technology. All other DM81xx releases support this functionality.

For EZSDK-based systems the procedure is slightly different:

(1) Take a USB drive (must be FAT32 format) and make a directory named “update”

(2) Copy the image to update with to the “update” directory and rename that file “z3.img”

(3) Plug the USB drive into the board and boot the board. You should see something like the following at the beginning of u-boot:

        U-Boot 2010.06 (Oct 15 2013 - 10:26:54)

        TI8168-GP rev 1.2

        ARM clk: 987MHz
        DDR clk: 796MHz
        DSS clk: 691MHz
        DSP clk: 864MHz

        I2C:   ready
        DRAM:  1 GiB
        NAND:  1024 MiB
        Net:   Detected MACID:84:7e:40:af:4a:30
        Ethernet PHY: GENERIC (x001cc915) @ 0x01
        DaVinci EMAC
        Press SPACE to abort autoboot in 0 seconds
        Booting from NAND and ubifs...
        USB:   scanning bus for devices... 1 USB Device(s) found
               scanning bus for storage devices... 1 Storage Device(s) found
        checking for Z3 software image ...
        reading software image from: /update/z3.img ...

        verifying image checksum ...
        firmware image detected: Z3 Netra 09-11-2011.
        writing firmware, please wait ...
        HW ECC BCH8 Selected
        SW ECC selected
        firmware has been successfully updated.
        resetting ...

The same note about selected USB drives being found to work mentioned above in the RDK procedure applies here as well.

Yes, there is on the DM81XX products.

For all EZSDK products and all DM816X RDK products, the procedure is as follows:

    (1) [Boot the board from NFS in u-boot (see the User's guide for how to do this)]
        Z3-DM8168-MOD# run boot-nfs
    
    (2) flash_eraseall /dev/mtd5
    
    (3) ubiattach /dev/ubi_ctrl -m 5 -O 2048
    
    (4) ubimkvol /dev/ubi0 -N rootfs -s 128MiB
    
    (5) mkdir /tmp/mynfsmnt
    
    (6) mount -o nolock 192.168.0.6:/home/z3/z3-netra/filesys/fs /tmp/mynfsmnt
          -Note:  "z3-netra" should be replaced by the appropriate project directory 
          -Examples: "z3-dm810x", "z3-dm814x", or "z3-netra-rdk"
    
    (7) mkdir /mnt/ubifs
    
    (8) mount -t ubifs ubi0:rootfs /mnt/ubifs
    
    (9) cp -a /tmp/mynfsmnt/* /mnt/ubifs/.
    
   (10) umount /mnt/ubifs
   
   (11) umount /tmp/mynfsmnt
   
   (12) [Reboot board, stop at u-boot, and enter the following]
        Z3-DM8168-MOD# setenv bootcmd run nand_boot_ubifs
        Z3-DM8168-MOD# saveenv   

For all DM8107 and DM814X RDK products, the procedure is the same as above, except “mtd5” in step (2) should be “mtd6”, and “-m 5” in step (3) should be “-m 6”.

Any SD card 32GB or less can be used.

First of all, we recommend trying the instructions in the latest User's Guide, which should have detailed instructions on setting up the TFTP server. It should be in a section titled “Method 2: Running Your Code through TFTP/NFS” (if your User's Guide does not have this section, please contact Z3 Technology).

If you try that sequence and TFTP is still not working, here are items, from our experience with previous customers, that you can check:

(a) Is the Ethernet connected well to both the Z3 Module and the TFTP server (check the link lights on both)?

(b) Check the netmask of the Z3 Module set in u-boot. Is it equal to the netmask of the TFTP server? (Default value = 255.255.0.0)

(c) Check the IP address of the Z3 Module set in u-boot. Is it one that can communicate with the TFTP server based on the netmask?

• For example, if the netmask is 255.255.0.0 and the TFTP server IP address is 192.168.0.6, then the Z3 Module can be set to an IP address of 192.168.x.y, where x.y is any value except “0.6”.

(d) Is there anything else on the network that might have the same IP address as the Z3 Module or the TFTP server that could be causing a conflict?

(e) Is there a firewall on the TFTP server PC that is turned on? (If so, you need to turn it off).

(f) Check the value of serverip in the u-boot parameters. Does it equal the IP address of the TFTP server? (Default value = 192.168.0.6).

(g) Was an “images” directory link set up and does the file uimage exist in that directory?

(h) If you take serverargs in /etc/xinetd.d/tftp and combine that with tftp_root in the u-boot arguments, does it point to the images directory?

(i) Did you start the tftp server? (In Ubuntu, this is done with a “sudo /etc/init.d/xinetd start”)

(j) If you made changes to /etc/xinetd.d/tftp, did you start the tftp server after making those changes?

(k) Is the permission of your /tftpboot directory set to “777” and the owner set to “nobody”?

First of all, we recommend trying the instructions in the latest User's Guide, which should have detailed instructions on setting up the NFS server. It should be in a section titled “Method 2: Running Your Code through TFTP/NFS” (if your User's Guide does not have this section, please contact Z3 Technology).

If you try that sequence and NFS is still not working, here are items, from our experience with previous customers, that you can check (note: items (a) through (e) are identical to the items in Question (1)).

(a) Is the Ethernet connected well to both the Z3 Module and the NFS server (check the link lights on both)?

(b) Check the netmask of the Z3 Module set in u-boot. Is it equal to the netmask of the NFS server? (Default value = 255.255.0.0)

(c) Check the IP address of the Z3 Module set in u-boot. Is it one that can communicate with the NFS server based on the netmask?

• For example, if the netmask is 255.255.0.0 and the NFS server IP address is 192.168.0.6, then the Z3 Module can be set to an IP address of 192.168.x.y, where x.y is any value except “0.6”.

(d) Is there anything else on the network that might have the same IP address as the Z3 Module or the NFS server that could be causing a conflict?

(e) Is there a firewall on the NFS server PC that is turned on? (If so, you need to turn it off).

(f) Check the value of nfsserver in the u-boot parameters. Does it equal the IP address of the NFS server? (Default value = 192.168.0.6).

(g) Was a “filesys” directory link set up?

(h) Does the IP address in the line added in /etc/exports match the IP address set in nfsserver in the u-boot environment?

(i) Does the value of nfs_root in the u-boot environment point to the filesys link that was set up?

(j) Did you start the nfs server?

(k) If you modified the exports file, did you remember to restart the nfs server after making your changes?

ZFinder will run on Windows XP and any Windows OS after that – including Windows Vista, Windows 7, and Windows 8.

Most of the time this is due to (a) A faulty Internet connection, or (b) An issue with the IP address on the board or PC. You can check the following:

(a) Is the Ethernet connected well to both the Z3 Module and the PC (check the link lights on both)?

(b) Check the netmask of the Z3 Module set in u-boot. Is it equal to the netmask of the PC? (Default value = 255.255.0.0)

(c) Check the IP address of the Z3 Module set in u-boot. Is it one that can communicate with the PC based on the netmask?

• For example, if the netmask is 255.255.0.0 and the PC IP address is 192.168.0.6, then the Z3 Module can be set to an IP address of 192.168.x.y, where x.y is any value except “0.6”.

(d) Is there anything else on the network that might have the same IP address as the Z3 Module or the PC that could be causing a conflict?

(e) Is there a firewall on the PC that is turned on? (If so, you need to turn it off).

90% of the time, the issue is with the value typed in for the URL on the decoder. Some customers type in the IP address of the encoder board here. This is not correct. The value that needs to be typed in here is the IP address which the encoder is streaming to. For example, let's say that an encoder board with IP address 192.168.81.68 is streaming to a decoder board with IP address 192.168.0.200. On the encode side, the URL could be set to

    udp://192.168.0.200:8888

On the decoder side, the URL must also be set to:

    udp://192.168.0.200:8888

This is also true for RTP streaming and also true for multicast IP addresses.

This can be changed in the source file $PRJROOT/z3apps/rdk/rdk_demo/demo_vdec_vdis.c. In line 79 of this file, change:

    int demoLayout = DEMO_LAYOUT_MODE_4CH_PIP

to:

    int demoLayout = DEMO_LAYOUT_MODE_1CH

These 3 lines are video blanking data and are unique to NTSC. Seeing these lines is possible if you are displaying the 480 lines of NTSC on a 488 line monitor. The recommended solution is to make the display buffer bigger and move the portion that is displayed down 3 lines.

Try renaming “.mpg” to “.ts.”

One thing to make sure of when decoding 1080p60 (or any progressive resolution) is that the display mode is set to 1080p60. If display mode is set to 1080i, this can cause an unnecessary increase in latency and can also cause quality degradation (most visible with sharp edges such as text). If 1080p60 display mode is set, the best possible latency and quality in the system will result.

Most of the time this is due to (a) A faulty Internet connection, or (b) An issue with the IP address on the board or PC. You can check the following:

(a) Is the Ethernet connected well to both the Z3 Module and the PC (check the link lights on both)?

(b) Check the netmask of the Z3 Module set in u-boot. Is it equal to the netmask of the PC? (Default value = 255.255.0.0)

(c) Check the IP address of the Z3 Module set in u-boot. Is it one that can communicate with the PC based on the netmask?

• For example, if the netmask is 255.255.0.0 and the PC IP address is 192.168.0.6, then the Z3 Module can be set to an IP address of 192.168.x.y, where x.y is any value except “0.6”.

(d) Is there anything else on the network that might have the same IP address as the Z3 Module or the PC that could be causing a conflict?

(e) Is there a firewall on the PC that is turned on? (If so, you need to turn it off).

Generally this is an issue of making sure that the address being streamed to matches the value entered in VLC. You can check the following:

(a) Does the IP address set in “Dest Address” in the encoder equal the IP address of the PC running VLC?

• Or, if a multicast address is being used (for example, 225.1.1.1), does this match the address entered in VLC?

(b) Does the port number in “Dest Port” equal the value entered in the URL for VLC?

(c) Does the video coming out of the source match the resolution in the encoder settings?

(d) Is the PC fast enough to handle 1080p decode on VLC?

(e) Is version 1.1x or later of VLC being used?

(f) Did you remember to type “udp” and “@” in the URL for VLC? (Both are needed).

The important thing here is to make sure the value of “Dest Port” matches the value which the User's Guide says to use (generally 5004). The User's Guide will say which value of Dest Port matches the sample SDP file provided by Z3.

(a) First, make sure the source is clean. Connect the video source directly to a monitor and confirm there are no issues.

(b) Second, try a different set of cables. More than a few times the issue turns out to be bad cables.

(c) Third, try a different source if possible. This will help determine if there is an issue between the source and the Z3 encoder.

(d) Fourth, try connecting to a PC with VLC and streaming using RTP or UDP. If the VLC plays clean then there is likely a decoder issue.

(e) Fifth, if a Z3 unit is being used for encode and another for decode, try switching them.

If you try all of the above and still encounter issues, please contact Z3.

The two settings that directly impact latency are “Maximum Delay” (called “Video Burst Size” on the DM368) and “Number of B-frames”. For the lowest possible latency, “Maximum Delay” should be set to 150, and “Number of B-frames” should be set to 1 (which disables B-frames).

RTP is also lower latency than UDP, so you should use RTP if possible.

Also, if you are streaming to VLC, you can reduce latency on the decode side by adjusting the network caching value. By default, this is set to 1000ms. You can lower this to as low as 200ms. To do this, go to the following:

• VLC → Tools → Preferences → Show Settings (ALL) → Input / Codecs → Network caching (ms)

These are most likely Macrovision rows. Some DVD players include this in the output while some don't. You can confirm this by seeing if the same artifacts occur with component input. If they don't, then this is very likely Macrovision data. Using a different DVD player may address this issue. Another alternative is to modify the application to crop those lines. Note, however, that for DVD players that do not output these lines, cropping can cause actual valid video data to be cut out of the picture.

In general Z3 recommends using the latest version of VLC (v2.0.7) to ensure you are getting maximum functionality and maximum performance.

The earliest version of VLC that will work with Z3's encoders is version 1.00. Using version 0.99 has been shown to produce artifacts in certain cases. The VideoLan website describes version 1.00 as follows:

• This major release introduces many new features, new formats and new codecs to the VLC multimedia framework and fixes a very high number of bugs that were present in the 0.9.x or 0.8.6 versions.

Based on this, an upgrade to at least 1.00 is advised.

Note that an issue has been observed with displaying the proper frame rate for .ts files (earlier versions may show double the expected frame rate in the statistics section). v2.1.3 and later do not show this issue.

The “Channels 1+2/3+4/5+6/7+8” is for digital audio, so in this case you would choose “Channels 1+2”.

You can ensure this by using any resolution / frame rate except 1080p60. For example, 1080p30 or 1080i30 produces (1920 *1080 * 30) / 256 = 243,000 macroblocks per second, which is just under the limit.

Yes, this is supported. To encode at those frequencies, either specify “Follow input”, which causes capture at whatever rate the video data is coming in at, or specify “30” for 29.97 or “60” for 59.94. In that case the system will autodetect that the input is actually 29.97 / 59.94 and encode at that rate.

Yes.

The encoder uses NAL units 1, 5-8, and 28.

Yes. This is in conformance with RFC3984, which states that start codes do not apply to RTP-encapsulated bitstreams. Annex B in RFC3984 makes a provision for including optional start codes. Z3's decoders can handle streams with start codes in the event Annex B is being used.

Yes. PPS headers are only sent at the beginning of each frame.

buf_period and pic_timing are generated in the SEI headers in Z3 streams.

This is possible to do on the RDK.

If encoding progressive, this can be done by duplicating CH1 to create a CH3 (and/or CH2 to create a CH4). After doing this, CH1 and CH3 can be used to encode the same progressive input at different resolutions, bitrates, frame rates etc.

If encoding interlaced, a splitter is required. In that case the 2 outputs on the splitter would go to CH1 in and CH2 in.

The most common cause for this is the file was saved in raw .h264 format. Raw .h264, while containing video data, does not contain any timing information. For this reason a decoder will often use a default value of 30fps. To accurately playback at 60fps, you need to save to a file format that has timing information, such as .ts or .avi.

The first thing to check is the VLC audio settings. If you bring VLC up its default settings often have audio at a low level so you need to manually increase it.

This has been observed as an issue in certain versions of VLC. The latest versions (v2.1.3 or later) do not have this issue.

It is possible for NULL packets to occur to meet the overall channel rate.

This can be specified with an additional “/” followed by the desired TTL at the end of the IP address. For example, to specify a TTL of 2, you could use the destination IP address of “225.1.2.3/2”. A default value of 1 is assumed.

The “right” bitrate can vary greatly depending on content used and customer expectation. With that in mind, here is a general set of bitrates we've found to work well:

* = 30 frames per second, or 60 fields per second
prog = Progressive
int = Interlaced

This is typically indicative of packet loss in the network. Please check your network to make sure it is not being overloaded. This message is discussed in the following link:

• http://stackoverflow.com/questions/25303570/aac-bitstream-not-in-adts-format-and-extradata-missing

The MVE-40, MVE-100, DM8169-4CH-RPS, and DM8169-VI-RPS (RDK) are the best products to use for minimal ASI latency. End-to-end latency of 1.3 seconds was observed here in testing. The amount of latency will vary depending on the decoder that is used.

To minimize latency, B-frames should be set to 0 and Video Delay should be set to as low a value as possible (150 was used in tests here).

Yes, Z3's encoders all generate Closed GOPs.

The following are the maximum recommended bitrates for streaming for each platform:

Note that, when encoding to a file, limitations of the media used may apply.

Yes, it does. A write-up on connecting with ustream is available. For details, please contact Z3 Technology.

When using Wowza in RTMP mode, a unicast address is required. Wowza supports multicast addresses in other modes, but not in RTMP mode.

No. There are no known restrictions to working with Adobe Media Server. Tests here ran with no issues.

In our tests, latency was reduced from 5.5s to 1.2s by going to Server - Performance Tuning - Java Settings and changing “Java Heap Size” to “Production Level” and “Java Garbage Collection” to “Concurrent collector.” Screenshot below:

The first thing to check is the firewall settings of the network – are the ports used for RTMP being blocked by a firewall? If so, modify the firewall settings to allow these ports to be used.

To setup GDB, you need to do 3 steps (steps w/ EZSDK shown here):

(a) Copy the threaddb libraries to the host

    cp -a $PRJROOTtoolchain/codesourcery_arm2009q1-203/arm-none-linux-gnueabi/libc/lib/libthread_db* $ROOTFS/fs/lib

(b) Create a .gdbinit file in your build directory

    cd $PRJROOT/ezsdk/component-sources/omx_05_02_00_46/src/z3

    set solib-absolute-prefix /home/z3/projects/z3/DM8169-VI-RPS/filesys/fs
    set solib-search-path /home/z3/projects/z3/DM8169-VI-RPS/filesys/fs/lib:/home/z3/projects/z3/DM8169-VI-RPS/filesys/fs/usr/lib:/home/z3/projects/z3/DM8169-VI-RPS/filesys/fs/opt/gstreamer/lib:/home/z3/projects/z3/DM8169-VI-RPS/filesys/fs/opt/gstreamer/lib/gstreamer-0.10
    cp -a $PRJROOTtoolchain/codesourcery_arm2009q1-203/arm-none-linux-gnueabi/libc/lib/libthread_db* $ROOTFS/fs/lib

(c) Find the executable and run it

    find ../../bin/ -name z3_v4l2\*.xv5T

         ../../bin/z3_v4l2/bin/ti816x-evm/z3_v4l2_a8host_debug.xv5T

    arm-none-linux-gnueabi-gdb ../../bin/z3_v4l2/bin/ti816x-evm/z3_v4l2_a8host_debug.xv5T

         target remote 192.168.81.68:5004

Also, the following information on post-mortem multithread debugging may be helpful:

• http://processors.wiki.ti.com/index.php/Multithreaded_Debugging_Made_Easier_by_Forcing_Core_Dumps

The gdb in the toolchain does have a dependency on 32-bit python 2.6 libraries. You may need to link to them. You can verify this is the issue if you see the following:

    arm-none-linux-gnueabi-gdb
    arm-none-linux-gnueabi-gdb: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory

If you see this and you are on 32-bit Ubuntu, you should point to the newer python to get gdb to come up:

    sudo ln -s libpython2.7.so.1.0 /usr/lib/libpython2.6.so.1.0

The sshd replacement “dropbear” is included in $PRJROOT/sysapps/dropbear-0.52. You can run it with the command:

    /usr/sbin/dropbear -E

The issue is probably missing RSA or DSS keys. You can verify this by running dropbear with the -E option:

    root@arago:~# dropbear -E -F -a
    [1618] Dec 02 19:03:59 Failed reading '/etc/dropbear/dropbear_rsa_host_key', disabling RSA
    [1618] Dec 02 19:03:59 Failed reading '/etc/dropbear/dropbear_dss_host_key', disabling DSS
    [1618] Dec 02 19:03:59 premature exit: No hostkeys available

The solution to this is to type the following:

    root@arago:~# mkdir /etc/dropbear
    root@arago:~# dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
    root@arago:~# dropbear

After doing this, you should see dropbear running with the ps command.

You can do this by using the “status” command. You can type:

    status item=ENCODERS

This will cause a printout of status for every encoder instance:

    +channel <id> URL <dest> frames <framecnt>

By checking <framecnt> you can tell if a particular channel has stopped.

Alternately, you can type:

    status item=i

This will print debug information about each instance to the file /tmp/debug.txt (a lot of information is printed out, so this should be used sparingly). In newer versions, this file is moved to /tmp/debuglog.d/current.

/tmp

Three files are useful:

(1) Screenshots of the settings used for the encode/decode (and the output to the console when running the session)

• You can also type “echo > /tmp/diag”, and then run the commands, and then send the file “diag”

(2) The file /tmp/debug.txt (in newer versions, this file is moved to /tmp/debuglog.d/current)

(3) If an encode is being done, the file /tmp/mcsenc.log

In some cases, the following may also be useful:

(4) The boot log

(5) The contents of dmesg

For EZSDK users, it can also be useful to run TI's “loggerSMDump.out” M3 firmware log utility and send the resulting log file. This utility is included in EZSDK releases and can be extracted using the following steps:

    [Go to $PRJROOT]
    source z3-env
    cd $PRJROOT/filesys/fs
    tar xvzf ../../ezsdk/filesystem/ezsdk-dm816x-evm-rootfs.tar.gz usr/share/ti/ti-uia

The above extracts the utility “loggerSMDump.out”. Details on running it can be found in:

• http://processors.wiki.ti.com/index.php/OMX_Viewing_Media_Controller_Traces

If there is an issue while booting, you can increase the log level at boot-up by typing the following commands in u-boot and then rebooting:

    setenv console ttyO2,115200 loglevel=8
    saveenv

This can be done using VLC. To use VLC to save to a .ts file, do the following:

(1) Open VLC on a PC that the Z3 unit is streaming to.

(2) Select “Media - Convert / Save” (for VLC running on Windows, this is “File - Convert / Save”).

(3) You should see “File”, “Disc”, “Network”, and “Capture Device” tabs. Click on the “Network” tab.

(4) In this tab, enter the same URL you would use to receive the stream. For example, if you are streaming using udp:

  udp://@192.168.0.6:5004

(5) Click on the “Convert/Save” button at the bottom.

(6) This will bring up the “Convert” Window. In this Window, click on “Browse” and specify the name of the file to save to.

(7) Click on the “Dump raw input” checkbox at the very bottom of the “Convert” Window.

(8) Click “Start”

The .ts file will start saving – you should see the file gradually growing.

(9) Either click the “Stop” button or select “Playback - Stop” to stop saving the stream.

(10) Exit VLC.

In both the RDK and EZSDK for the DM81xx, the watchdog enable is currently done in /opt/webgui/server.sh

To disable the watchdog, you need to:

(1) Comment out the watchdog task in /opt/webgui/server.sh

  # watchdog /dev/watchdog &

(2) Run 'sync' to make sure your changes are saved

(3) Reboot the board

  reboot -f

The web server log, HTML and Javascript are in:

• z3apps/webgui/gui/web

The Javascript files (*.js) take care of dynamic aspects (such as disabling options based on the current configuration and populating dynamic listboxes), as well as transferring the form values to the user interface.

If you add a new item to the web interface, you will need to add code to one of the following functions:

• encoder.js:encoder_init()
• decoder.js:decoder_init()
• system.js:system_init()

to transfer the configuration parameter to the HTML DOM.

All configuration accesses go through the file:

• z3apps/webgui/gui/web/cgi-bin/control.cgi

If you want to add a configuration item, add it to the appropriate variable:

• CONFIG_ARGS_DEC
• CONFIG_ARGS_ENC
• CONFIG_ARGS_COMMON

We use lighttpd.

The most important thing (as noted in the DM816X-MOD Hardware Specifications) is you need to make sure that the MOD-35 is configured as a Root Complex (“-RC”). The -RC boards include a 100MHz oscillator to act as the PCIe clock. This is also used to drive the SATA.

If the MOD-35 is configured as an -EP board, it is still possible to connect with SATA if an external oscillator is used to drive the SATA interface.

The first thing we recommend checking is that the board ID is set to whichever Z3 application board was used as the reference point. For several customers fixing this was the key step to getting video frames coming in. Details on setting board ID can be found the RDK Developer's Guide. For information on setting this on an EZSDK system, please contact Z3.

This can be accomplished through the following commands:

    cd $PRJROOT/dvr-rdk
    make dvr_rdk_linux dvr_rdk_bios6 install

One common cause is configuring the VIP for falling edge when it should be rising edge.

On the DM816X, this information can be found in:

    ./arch/arm/mach-omap2/ti81xx_vpss.c

More information can also be found on the following TI Wiki page:

• http://processors.wiki.ti.com/index.php/TI811X_PSP_Adding_External_Decoders_to_V4L2_Capture_Driver

The default mode is “telnet” mode, where any 0xff character received by TCP is interpreted as the beginning of a telnet IAC command sequence.

It is also possible to set a clearchannel mode, where the TCP data is not altered in any way.

You can try using netcat. For example, you can run netcat on a Linux PC as a server on TCP port 7777:

    nc -l 7777

Then run netcat on a Linux PC as a client, conncting to the ZTermSrv server at 192.168.0.65 TCP port 9999:

    nc 192.168.0.65 9999

Yes you can, by specifying multiple “-v” options. For example:

    ./rtptx -v rtp://192.168.0.6:8888 -v rtp://192.168.0.6:8900

For more details, please see the “RTPTX User's Guide (v1.3)” (DOC-USR-0007-01).

There is a “giodebug” utility available which can read or write GPIOs.

When working with GPIO, it is important to keep in mind that some pins have multiple functions, so handling pinmuxing properly is a must. The best place to get started with details on pinmuxing is Section 9.12.2 (“Pin Mux”) in the DM36X ARM Subsystem Guide (SPRUFG5A):

• http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=SPRUFG5&fileType=pdf

Yes. There is an encode sample app with OSD support. To run it, type the following:

    cd /opt/dvsdk
    ./loadmodules_sd.sh
    ./encode -v /tmp/out.264 --osd -y 1

There is full documentation for the encode command in the file

    /opt/dvsdk/encode.txt

on the target.

Yes. The latest versions of Z3's DM368 software support this.

You can look at /proc/davinci_clocks.

Yes. The DM368 supports resizing to any resolution shown in the drop-down menus.

Yes. There is an existing API to set analog input volume at startup time:

    dvsdk/dvsdk_2_10_00_17/dmai_1_21_00_10/packages/ti/sdo/dmai/linux/Sound_alsa.c

    /** @brief Gain between 0-100 of the left channel */
    Int32                leftGain;

    /** @brief Gain between 0-100 of the right channel */
    Int32                rightGain;

There is no API for digital volume – this could be implemented by the customer by using a saturating 16-bit signed multiplication on all audio samples.

There is no command line option for this. However, there is example code in:

• dvsdk/dvsdk_2_10_00_17/dmai_1_21_00_10/packages/ti/sdo/dmai/linux/Sound_alsa.c:setMixerVolume()

this shows how to set the ALSA mixer volume. Setting this to 0 would be the equivalent of muting.

rtptx has a “–videopar” argument you can use. For example, for PAL widescreen, you can set:

    --videopar=16:11

and for NTSC widescreen you can set:

    --videopar=40:33

It is connected to PWRCTRLIO5 (see dm368_board.c). Drivers in u-boot and the linux kernel for this pin can be found in:

    kernels/linux/arch/arm/mach-davinci/prtcss.c
    u-boot/u-boot-1.3.4/board/davinci/dm365_evm/prtcss.c

The external reset to the 8700C is provided by the MSP430. The MSP430 generates reset based on 2 inputs: One is the reset signal generated when the reset button on the board is pushed, and another is based on a circuit which checks the current Vcc, and asserts reset as long as Vcc is below a certain level.

The DM368 MOD uses 1 chip select with the NAND – CE0. There would be no conflict with CE1.

You can check the PINMUX2 register at address 0x1c40008:

    /opt/dvsdk # devmem 0x1c40008
    0x00001855

The oe# and we# signals are used by the NAND.

Yes. You can use the “-p” (or “–program”) option in tsplayer to select the program, and “–pids” to select specific PIDs to demux.

To change files on the DM36x filesystem, you need to make it writable first:

    mount -o remount,rw /
    
    < Make changes by vi on the board or by copying files >

    mount -o remount,ro /

The timeout command can be found by running

    grep -e 'read -t'  /opt/dvsdk/*.sh

See question (17) on making the DM368 file system writable so changes can be made.

Any firmware released in 2012 or later supports up to 32GB.

Yes they are.

Somehow mtd5 got in an unknown state in the update process. You can get mtd5 back in a known state by typing:

    flash_eraseall /dev/mtd5

The DM368-SDI-RPS and DM368-VI-RPS require a power cycle between changing from encoder to decoder mode. Note that a power cycle is not needed for the DM368-RPS.

This can happen if high bitrates are used for sub-D1 resolutions (for example, > 1Mbps for CIF). To avoid this,use bitrates less than 1Mbps for sub-D1 resolutions.

It could also potentially happen for very high bitrates for D1.

A thread on this issue can be found on E2E at http://e2e.ti.com/support/embedded/multimedia_software_codecs/f/356/t/128489.aspx

The full message is:

    zrecorder: linux/Capture.c:1196: Capture_get: Assertion `hCapture' failed. 

This is an indicator that valid video input was not detected. Please recheck your video sources.

Yes it is. The DM368-based products will automatically detect 29.97 and 59.94 Hz and encode at that rate.

Behavior at startup is controlled in /root/.profile on the board filesystem.

The specifications are:

• Input level: 1.4Vrms (Zin=2K) (4Vpp)
• Line level, 6dB of attenuation

These specifications and additional details can be found in the DM368 HW datasheet from TI.

This points to the Ethernet switch getting overloaded. You can try adjusting the delay between packets with the parameter “–interpacketgap”. The default value is 150 microseconds.

Another option is to use TS, which paces out the output.

Use the “port” value to select. “1” is the first program, “2” is the second program etc.

The middle BNC connector is used for ASI In (same as “SDI In”). The left BNC connector is used for SDI Out (same as “ASI Out”).

ubl_DM36x_nand_270_243.bin is for nominal timing for the DM365.

ubl_DM36x_nand_297_270.bin is for 720p30 capable timing for the DM365.

ubl_DM36x_nand_432_378.bin is for the DM368.

Yes. RTPRX supports HDMI output. Select the “component” option to cause video data to go to the HDMI. It may also be necessary to run the HDMI driver. This can be done by typing the following before running RTPRX:

    /root/ad9889 > /dev/null &

The MAC address can be changed in u-boot by doing the following steps:

(a) Get the u-boot prompt by pressing the spacebar within 3 seconds of powering on the board.

(b) Through the serial interface, type “setenv ethaddr XX:XX:XX:XX:XX”, where “XX:XX:XX:XX:XX” is the MAC address you want to assign.

(c) Confirm the value is what you want by typing “printenv ethaddr”.

(d) Save the values by typing “saveenv”.

VFAT and EXT3 are supported.

For VFAT, the limit is 32GB. For EXT3, the limit is 2TB.

Yes it is. To do this, save the settings while an encode is running.

The following will work for 720p59.94:

    echo 0 > /sys/devices/platform/vpss/display1/enabled
    echo "74176,1280/110/220/40,720/5/20/5,1" > /sys/devices/platform/vpss/display1/timings
    echo 74175824 >  /proc/fpga/sdiout_video_rate  
    echo 1 > /sys/devices/platform/vpss/display1/enabled

Yes. As long as it is loaded before it is actually needed there should be no issue in delaying loading of it.

Instead of the customary names

• /dev/ttyS[0123..]

the DM81xx uses

• /dev/ttyO[0123..]

For the DM816x, Z3 exports the UART0 and UART1 signals on the module connector. To use these ports, the customer just needs to use the appropriate device names.

If the customer wants to use UART2, they can just replace Z3's entries in /etc/inittab and set the console= variable in u-boot to point to an unused serial port.

We have seen customers succeed in getting rid of this by setting in kernels/linux/.config:

    CONFIG_MUSB_PIO_ONLY=y

This pin is no longer supported by TI. If you check the latest DM8168 datasheet, this pin is marked as “reserved.” Also, the following link mentions this is no longer supported:

• http://processors.wiki.ti.com/index.php/DM816x_C6A816x_AM389x_PSP_04.00.00.12_Feature_Performance_Guide

This message occurs in EZSDK 5.05.02.00 even with no changes done by Z3. We believe this message can be ignored.

There are 5 files that are of interest:

    kernels/linux/drivers/media/video/netra/dummy_vpif.c 
    kernels/linux/drivers/media/video/adv7611.c
    z3apps/drivers/hdmi/ad7611/init_7611_edid.sh
    ezsdk/component-sources/omx_05_02_00_48/src/z3/z3_v4l2.c.
    ezsdk/component-sources/omx_05_02_00_48/examples/ti/omx/demos/capture_encode/src/ilclient.c    

“dummy_vpif.c” contains the code for the netra_autodetect.ko driver used to setup the video mux and detect incoming video input standards.

“adv7611.c” contains the code for the Analog Devices 7611 HDMI frontend chip.

“init_7611_edid.sh” is the init script that sets up the proper drivers based on the board ID.

“z3_v4l2.c” calls the ioctls provided by the netra_autodetect driver.

Finally, “ilclient.c” is an example of using the netra_autodetect driver in an EZSDK application.

Z3 boards are set up to share the video bus on the DM816x with several devices. In order to accomplish this, the devices are muxed and the desired input is selected via the netra_autodetect.ko kernel driver. The code for this driver is contained in dummy_vpif.c. The user space call of this code is located in z3_v4l2.c. All Z3 EZSDK applications requiring video input call the z3_v4l2_capture_autodetect() function in this file to set up the mux properly. An example of this can be found in ilclient.c. V4L2 then takes over and uses the driver for the front end chip (for example, adv7611.c for HDMI inputs) to configure the chip.

adv7611 i2c_boardinfo is assigned at runtime using the v4l2_i2c_new_subdev_board() API in $PRJROOT/kernels/linux/drivers/media/video/netra/dummy_vpif.c (see also question (7) for details).

There is one aic3x on the MOD-2x board on I2C0, and a second aic3x on the APP-02 board on I2C1.

Alpha blending can be implemented using the sysfs variables documented in:

    ezsdk/board-support/docs/TI81XX_VPSS_Video_Driver_User_Guide.pdf

There is an example of using alpha blending in:

    ezsdk/component-sources/omx_*/examples/ti/omx/demos/decode_display/src/Fb_blending.c

which can be exercised using the “-g 1” option to decode_display.

“Video windows” can be implemented by using transparency keying values in the frame buffer, and using a single video pipeline with the video positioned in the same location as the transparency key in the framebuffer.

If multiple windows are needed, they can be “painted” onto the same video window, using the mosaic method as in this sample application:

    ezsdk/component-sources/omx_*/examples/ti/omx/demos/decode_mosaicdisplay

The following example can be found in the code:

    if (pAppData->eCompressionFormat == OMX_VIDEO_CodingMPEG2) { 
        if ( captureAspectWidth == 16 && captureAspectHeight == 9 ) {
            tDynParams.videoDynamicParams.h264EncDynamicParams.videnc2DynamicParams.sampleAspectRatioWidth = 7;
        } else if ( captureAspectWidth == 1 && captureAspectHeight == 1 ) {
            tDynParams.videoDynamicParams.h264EncDynamicParams.videnc2DynamicParams.sampleAspectRatioWidth = 3;
        }
        else if ( captureAspectWidth == 4 && captureAspectHeight == 3 ) {
            tDynParams.videoDynamicParams.h264EncDynamicParams.videnc2DynamicParams.sampleAspectRatioWidth = 5;
        } 
        else if ( captureAspectWidth == 15 && captureAspectHeight == 11 ) {
            tDynParams.videoDynamicParams.h264EncDynamicParams.videnc2DynamicParams.sampleAspectRatioWidth = 5;
        } 
        else {
            tDynParams.videoDynamicParams.h264EncDynamicParams.videnc2DynamicParams.sampleAspectRatioWidth  = 0; 
        }
        tDynParams.videoDynamicParams.h264EncDynamicParams.videnc2DynamicParams.sampleAspectRatioHeight = 0; // bit stuffing enable
    }

Yes, there is. The AAC-LC encoder and decoder are integrated into the EZSDK using OpenMax. Example code can be found in the directory:

    $PRJROOT/ezsdk/component-sources/omx_05_02_00_48/src/ti/omx/comp/aenc
    $PRJROOT/ezsdk/component-sources/omx_05_02_00_48/src/ti/omx/comp/adec

and an example of exercising the algorithms from the host can be found in:

    $PRJROOT/ezsdk/component-sources/omx_05_02_00_48/examples/ti/omx/demos/adec_snt
    $PRJROOT/ezsdk/component-sources/omx_05_02_00_48/examples/ti/omx/demos/audio_encode

An example can be found in:

    $PRJROOT/ezsdk/example-applications/linux-driver-examples-psp04.04.00.01/edma

In the file:

    /opt/z3/init_7611_edid.sh

there is the statement

    USE_V4L2=0

Here, change USE_V4L2=0 to USE_V4L2=1. This will run a V4L2 loopback from the the TVP7002 to the HDMI output.

In later versions of the code, it may be necessary to swap I2C addresses in:

    $PRJROOT/kernels/linux/arch/arm/mach-omap2/ti81xx_vpss.c

Specifically, instance 0 should be set to 0x5c and instance 1 to 0x5d.

Typically, one uses /dev/mem to gain uncached access to physical memory. Details can be found in:

    $PRJROOT/sysapps/busybox/miscutils/devmem.c

You can check the current pinmuxing through the following commands:

    mount -t debugfs none /sys/kernel/debug
    cd /sys/kernel/debug/omap_mux
    cat *

You can modify the pinmux by writing a hex value to the register. Here is an example from the FPGA load script on the DM8107-SDI-RPS:

    mountpoint /sys/kernel/debug || mount -t debugfs none /sys/kernel/debug

    echo 0x10010 > /sys/kernel/debug/omap_mux/vout1_g_y_yc1
    echo 0x10010 > /sys/kernel/debug/omap_mux/vout1_g_y_yc0
    echo 0x10010 > /sys/kernel/debug/omap_mux/vout1_r_cr1

Also, driving GPIOs are described more here:

• http://processors.wiki.ti.com/index.php/TI81XX_PSP_GPIO_Driver_User_Guide

There is support for scaling in the frame buffer. For more information, the customer can look up

     TIFB_SET_SCINFO

in

    $PRJROOT/dvr-rdk/ti_tools/linux_lsp/collaterals/collaterals/docs$ evince TI81XX_PSP_VPSS_Video_Driver_User_Guide.pdf

i2cdetect and i2cdump can be unreliable sometimes. It is better to use “i2c probe” in u-boot for debug.

This is not needed. There are 2 parts to initializing the AIC device. The first is the init in board-ti8169-evm.c, which by itself does not have any effect. The second is in kernels/linux/sound/soc/davinci/davinci-evm.c which, based on the board ID, drives instantiation.

Use “Arm-arago-linux-gnueabi” in dvr-rdk/ti_tools/cgt_a8/argo/linux-devkit. The $(CROSS_COMPILE) variable should already be set up to use this path when z3-env is sourced.

The memory maps for the ti816x platform are located here:

    prjroot/dvr-rdk/dvr_rdk/mcfw/src_bios6/cfg/ti816x/config_1G_256MLinux.bld

The Linux memory is reserved in the first 512MB block as seen in the excerpt from the .bld file below. In order to give Linux more memory, you will need to reallocate it from elsewhere. Another option is to reserve less VRAM via bootargs_misc.

    /* first 512MB */
    LINUX_SIZE                 = 256*MB;
    SR1_SIZE                   = 201*MB;
    SR3_INTRADUCATI_IPC_SIZE   =          124*KB;
    VIDEO_M3_CODE_SIZE         =  2*MB  + 512*KB;
    VIDEO_M3_BSS_SIZE          = 11*MB  + 512*KB;
    VIDEO_M3_DATA_SIZE         =  2*MB  + 512*KB;
    DSS_M3_CODE_SIZE           =  1*MB  + 512*KB;
    DSS_M3_BSS_SIZE            = 16*MB  + 512*KB;
    DSS_M3_DATA_SIZE           =  4*MB  + 512*KB;
    DSP_CODE_SIZE              =  800*KB;/*1*MB;*/
    DSP_DATA_SIZE              = 15*MB  + 100*KB;//100*KB;

Z3 currently reserves 20MB of VRAM via the bootargs_misc variable in u-boot. To change this, change the following line in $PRJROOT/dvr-rdk/dvr_rdk/bin/ti816x/load.sh to have the VRAM usage less than the bootargs_misc VRAM setting:

insmod ./kermod/ti81xxfb.ko vram=0:8M,1:8M,2:4M

Also, if LINUX_SIZE is increased, it is necessary to also adjust the mem= to reflect this in the bootargs_misc u-boot variable.

(a) As part of the kernel boot, the following /etc/rc.5 scripts are run:

     *S10load-hdvicp2-firmware.sh      -> ../init.d/load-hdvicp2-firmware.sh     [kernel video module]
     *S15load-hdvpss-firmware.sh       -> ../init.d/load-hdvpss-firmware.sh      [kernel video module]
     *S16load-dsp-firmware.sh          -> ../init.d/load-dsp-firmware.sh         [kernel video module]
     *S98z3.sh                         -> /opt/z3/init_7611_edid.sh              [set up app board video enc/dec via i2c/FPGA]
     *S99z3demo -> ../init.d/z3demo                                              [start DVR demo]

(b) “z3demo” creates and executes

    */tmp/z3start.tmp

(c) “z3start.tmp” then runs

     */opt/dvr_rdk/ti816x/runz3demo.sh

(d) “runz3demo.sh” pulls the name of the application to run passed by u-boot from the kernel cmdline and calls the desired script(s) based on that. In the default case 3 scripts are run:

    *init.sh        Removes previously loaded modules and reloads syslink.ko
    *load.sh        Loads DVR video driver modules
    *run_mcsenc.sh  Starts the demo and creates the FIFOs for communication with the demo application

(e) The demo application is then started in the background:

    *bin/mcfw_mcsenc -> z3_dvr_rdk_demo_mcfw_api.out

It is 16BIT YUV422P.

It should be. It looks like others have gone down this road (DM81xx RC with FPGA EP) and TI has some suggested patches to allow PCI rescanning. See the following threads:

• http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/154734/569707.aspx#581061
• http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/239588.aspx?pi199607=1

Please see the following documentation that is included in the build:

    $PRJROOT/dvr-rdk/ti_tools/linux_lsp/collaterals/collaterals/docs/TI81XX_PSP_VPSS_Video_Driver_User_Guide.pdf

Specifically, page 19 under the Transparency Keying heading. Basically, you need to set a background color for the area of the screen you are not using and then set up the Transparency Keying to make that color transparent. There are examples on how to do this in the document.

On the DM8107, voltage is controlled through the TPS65911 regulator. The voltages for the TPS65911 can be read in two ways. The first is via i2c from address 0x2D (assuming the chip is not in Smart Reflex mode):

The default value for all 3 of these voltages is 1.2V.

The second way to read the TPS65911 voltages is by setting the following in your kernel config (should be default):

CONFIG_MFD_TPS65910=y
CONFIG_REGULATOR_TPS65910

If the TPS65910 regulator driver is enabled, the voltage can be read from sysfs:

root@arago:~# cat /sys/class/regulator/regulator.5/microvolts 
1200000

To allow the automatic setting of the regulator based on CPU frequency, cpufreq has to be enabled in the kernel. Also, an opp file containing the available frequencies and their corresponding voltages needs to be added to '/arch/arm/mach-omap2/'. Lastly, in '/arch/arm/mach-omap2/cpu-omap.c', the correct device needs to be passed to regulator_get so the correct set_voltage function will be called. See http://processors.wiki.ti.com/index.php/TI81XX_PSP_PM_DVFS_User_Guide

Below is an example of how to dynamically change the A8 frequency:

   #Set the governor to the userspace governor
   echo -n "userspace" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   #Set the clock speed to 720MHz
   echo -n "720000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed 
   #Set the clock speed to 1000MHz
   echo -n "1000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

In order to turn Smart Reflex off, set the following in the kernel config:

CONFIG_REGULATOR_GPIO=n

When adding a new resolution to the RDK HDVPSS driver, several files need to be edited:

• prjroot/dvr-rdk/dvr_rdk/mcfw/interfaces/link_api/system_const.h
  • The new resolution needs to be added to the SYSTEM_Standard enum

  •     SYSTEM_STD_1080I_48,
        /**< 1920x1080 48FPS interlaced HD standard. */
        

• prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/vps/fvid2.h
  • The FVID2_Standard enum needs to match the SYSTEM_Standard enum from above.

  •     FVID2_STD_1080I_48,
        /**< 1920x1080 48FPS interlaced HD standard. */
        

• prjroot/kernels/linux/include/linux/fvid2.h
  • Propagate the DVR-RDK fvid2.h changes to Linux.

• prjroot/dvr-rdk/dvr_rdk/mcfw/src_bios6/links_common/system/system_common.c
  • This file contains compile time checks for match FVID2_Standard and SYSTEM_Standard enums.

  • UTILS_COMPILETIME_ASSERT(SYSTEM_STD_1080I_48 == FVID2_STD_1080I_48);

• The following files all require the addition of the new standard:
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/vps/drivers/src/fvid2_drvMgr.c
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/vps/hal/src/vpshalHdVencDefaults.h
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/vps/hal/src/vpshal_hdvenc.c
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/devices/sii9022a/src/vpsdrv_sii9022a.c
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/platforms/src/vps_platform.c
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/platforms/ti816x/src/vps_platformTI816x.c
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/platforms/ti814x/src/vps_platformTI814x.c
  • prjroot/dvr-rdk/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/platforms/ti8107/src/vps_platformTI8107.c

To add new standards to V4L2 the following modifications need to be made:

• A new extended standard needs to be added to both prjroot/dvr-rdk/dvr_rdk/mcfw/src_linux/devices/z3_v4l2/videohd.h and prjroot/kernels/linux/inculde/media/davinci/videohd.h

  /* Z3 - Digital TV standards EXT */
  /* if V4L2_STD_EXT denotes the these standards */
  #define V4L2_STD_1080I_24       ((v4l2_std_id)(0x0000800000000001ULL))

• Processing for the new resolution needs to be added to prjroot/dvr-rdk/dvr_rdk/mcfw/src_linux/devices/z3_v4l2/z3_v4l2.c

  case  V4L2_STD_1080I_24: 
     pStatus->isVideoDetect = TRUE;
     pStatus->frameWidth = 1920;
     pStatus->frameHeight = 1080;
     pStatus->frameInterval = 1000000/24;
     pStatus->isInterlaced = TRUE;
     pStatus->systemVideoStandard = SYSTEM_STD_1080I_48;
     *pStartX = 192;
     *pStartY = 36;
     break;

• Also, detection code needs to be added to the appropriate video drivers.

On the Z3 RDK-based platforms, up to 9 different configurations can be saved.

The latest versions of the RDK contain an “Encode 1 to 3 Ch” mode. This can be used to take the same input and encode it in 2 or 3 different ways.

The serial menu is run from one of the following 2 scripts:

    $PRJROOT/dvr-rdk/dvr_rdk/bin/common/run_mcsenc.sh 

    $PRJROOT/dvr-rdk/dvr_rdk/bin/common/run_mcsdec.sh 

These files are copied to the board filesystem at /opt/dvr-rdk/ti816x.

Note that there also may be an /opt/dvsdk directory. Those files are for different platforms and can be disregarded. Only files in /opt/dvr-rdk should be examined for RDK development.

The RDK will convert the interlaced source to progressive by taking one field and resizing it to full size. It will then encode that result as a progressive stream.

This refers to code that applies to the H.264 TruView encoder – an enhanced quality version of the H264 encoder. This TruView encoder is available to those that license DM8169 systems.

There should be no issue with doing this. “relatime” is used because it was the default option. Changing to “noatime” should not cause any issues.

Some are set up in u-boot and some in linux. In u-boot many of the addresses can be found in

   arch/arm/include/asm/arch-ti81xx

Addresses not found there can be found in the TI chip documentation.

This is indicative that encmode was not set. Make sure that encmode was set before running the encode command.

A few examples can be found in the file runz3demo.sh. A good example is at line 46:

echo "starting mcsenc"
         . /opt/mcsenc/mcsenc.sh 
         echo "starting component1"
         ${ZDVR_HOME}/zencode.sh instance=1 source=COMPONENT1  dst=file:///root/videos/component1_out_${APPEND_STR}.h264 vratediv=1 size=1280x720 vrate=4M audio=off
         echo "starting HDMI2"
         ${ZDVR_HOME}/zencode.sh instance=2 source=HDMI2 dst=file:///root/videos/hdmi2_out_${APPEND_STR}.h264 vratediv=1 vrate=4M size=1280x720 audio=off
         echo "file demo started"

Examples can be found in the file run_mcsenc.sh and in the Web GUI scripts. It is referred to as WORKING_CONFIG in these scripts.

You can use the following command:

    make -C dvr-rdk/dvr_rdk dvr_rdk_linux && make install

You should be able to do this by setting the busInterfaceType to 1 in the MultiCh_dectectStd(vipIst, videoDecoderName,capstatus,0, busInterfaceType) command. In fact, if “:RGB” is placed after the SRC in the MCSENC command, this automatically gets set (for example: “HDMI:RGB”).

We use the arago toolchain distributed with TI's RDK release. It can be found in:

    $PRJROOT/dvr-rdk/ti_tools/cgt_a8/arago/linux-devkit/arm-arago-linux-gnueabi

You can find these out using the “Z” command within the serial menu.

Yes it is.

Yes it is. There are 2 ways this can be done. The first is by changing the bitrate in the Web GUI and clicking the “update” button. The second is to use the “dynamic” command in MCSENC.

This is indicative of the one of the 2 ribbon connectors in the back of the module being loose. Please double-check those connections.

There are 3 steps you should take to do this:

(1) Set the power jumper (J21) on the APP-22 board to 2-3 to accept power from the PCI bus (the jumper goes on the right 2 pins). If an APP-41 is being used, this step is not necessary.

(2) Set the boot mode jumper on the module to PCI boot mode (1-2, 9-10).

(3) Make sure the motherboard connected to is a supported motherboard (see question (14)).

See the User's Guide for more details.

The composite output always outputs whatever is sent through the HDMI output. Whenever a resolution larger than NTSC is output on HDMI, the DM8107-RPS automatically resizes to NTSC before outputting through composite output.

The best way to do this is to remove “S99webserver.sh” from /etc/rc5.d on the system.

After telnet'ing into the board, you can type the following command (for DM816X products):

  
   /opt/dvr_rdk/ti816x/run_mcsenc.sh

For DM8107 and DM8148 products, the “ti816x” would change to “ti810x” and “ti814x”, respectively.

This can be done by editing the “console” environment variable in u-boot. Currently it is set to:

   console=ttyO0,115200,quiet

You can reroute the console output to the second serial port instead by typing while in the Linux prompt on your target board:

   fw_setenv console=ttyO1,115200,quiet

You also need to edit /etc/inittab to keep getty from respawning on ttyO0.

The serial number on each board has the following form:

  mmmmmmyywwsssss

  mmmmmm = model number (i.e. 300012 means 30-0012)
  yyww   = manufacturing date code, ww=week, yy=year
  sssss  = serial number

For example, a serial number of “30002101133810001” would indicate:

  Model # = 30-0021-01 (Rev 1 of the DM8107-MOD-02)
  Year    = 2013
  Week    = 38
  Serial  = 10001

On the DM814x and DM816x modules, the RTC is controlled through code that can be programmed through a free Elprotronic utility. A TI MSP430 programmer is needed. Some sample linux utilities to exercise the code are also provided. Detailed instructions on programming the RTC, verifying operation in u-boot, and verifying operation in linux can be found here.

For details on programming the RTC on the DM368 or DM8107 products, please contact Z3.

For the DM814x and DM816x modules, CR1220 or CR1225 batteries can be used.

All Z3 firmware updates contain 2 versions – an “UPD” and a “MFR” version. They are identical with the one difference that the “MFR” version changes all of the u-boot environment variables (IP address, netmask, TFTP server location, NFS server location etc) to default values. This is the version that the manufacturer loads when the boards are first made. The “UPD” version does not modify the u-boot environment variables. If you have already configured the software to work in your environment, you can use “UPD” to preserve the u-boot environment variable changes you had done before. In most situations the “UPD” is the best to use.

From the Linux prompt, type “reboot -f”.

You can do this by changing the value of “ipaddr” within the u-boot environment. If you have an RPS User's Guide, there is a detailed description of how to do this. Alternately, you can use the “fw_setenv” command within Linux from the serial interface. From a serial demo menu, select “X” to exit. This should bring you to an arago login prompt. Type “root” and then <enter>. From there, you can use “fw_setenv ipaddr” to set the IP address you want to use at boot-up. For example, to change this to 192.168.0.6, you would type:

    fw_setenv ipaddr 192.168.0.6

You can then type

    reboot -f

to reboot the board and have your settings take effect. As a side note, “fw_printenv” can be used to find current values of u-boot environment variables.

On a DM365/DM368, the procedure is slightly different. Instead of “fw_setenv ipaddr 192.168.0.6” you would type the following commands:

    read_ubootenv_from_flash.sh
    fw_setenv_target ipaddr 192.168.0.65
    write_ubootenv_to_flash.sh

When this happened before the root cause ended up being that the power supply for the SATA drive was not large enough. We recommend you double-check the power supply to the SATA drive if you encounter this message.

Yes. You can use the function tsmux_add_user_table() to support this. This applies to both the EZSDK and the RDK.

1) Download and install Wireshark and associated programs to enable live stream capture on the PC you already use VLC Media Player. A Restart will be required once installation is complete.

2) Set encoder for RTP/RTSP transfer and begin encoding as described in your product's manual.

3) Open Wireshark. Double click the “Ethernet” near the center of the window to automatically begin capture.

4) Open VLC Media Player on the Same PC and begin Streaming RTSP as described in your product's manual.

5) Allow Stream to capture for 1 minute. Click the Red Stop button on the menu bar of Wireshark.

6) Hit <cntrl+S> or the Save button at the top of the window to open a save dialog. Give the file a name of your choice that you will remember.

7) Attach the saved file to an email and send it to Z3 Technology.

To reset a forgotten password you will need physical access to the unit.

Create a file called z3passreset on an empty SD Card or USB flash drive; insert the SD Card or USB flash drive and power cycle the unit to reset the password to nothing.