Hang-up issue loading dm816x_hdvpss.xem3 firmware

David Soto - RidgeRun

Other Parts Discussed in Thread: TVP7002

Hi All,

I'm working with the following hw and sw components:

Hardware: Z3-DM8168-APP-02 (RPS), DRAM: 1 GiB (http://www.z3technology.com/Z3-DM8168-MOD.htm)

Software: EZSDK 5.02.00.57: (http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/5_02_00_57/index_FDS.html )

Problem:
I have been able to built and install properly the whole EZSDK in the DM8168-Z3 module, including OpenMax demos to encode and display H264. However, when I try to load the VPSS firmware called dm816x_hdvpss.xem3 using the EZSDK media-controller utility called firmware_loader, it hangs for a while (5 to 10minutes) and then it shows a message saying that the VPSS has started successfully. I have tested the same kernel image on the DM8168-EVM and it loads the firmware in less than 10 seconds, I was wondering what might be causing this problem in the Z3 module. Moreover, there is not time difference between the EVM and the Z3 loading the firmware into the HDVICP2.

According with other post (http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/98209.aspx) I suspect that I might be due to differences between the daughter card and the Z3-DM8168-RPS hw. If so, does anybody know how to modify the dm816x_hdvpss.xem3 firmware to reduce the load time in the Z3 hw?

I have set the memory map according with the EZSDK memory map webpage ( http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map)

These are my bootargs:

console=ttyO2,115200n8 notifyk.vpssm3_sva=0xBF900000 root=/dev/nfs nfsroot=<myIPAddress>:<pathOfMyNFS> rw ip=dhcp mem=256M

These are the steps that I'm following to load the firmware into the VPSS M3:

modprobe syslink TRACE=1 TRACEFAILURE=1
firmware_loader 2 /lib/firmware/dm816x_hdvpss.xem3 start /lib/firmware/mm_dm81xxbm.bin (5 to 10minutes to load the firmware)
firmware_loader 1 /lib/firmware/dm816x_hdvicp.xem3 start /lib/firmware/mm_dm81xxbm.bin (less than 10sec to load the firmware)
modprobe vpss sbufaddr=0xBFB00000 i2c_mode=1
modprobe ti81xxfb
modprobe ti81xxhdmi
rmmod ti81xxvo

Once this has been done, the decode_display demo provided in the EZSDK runs without errors, however I'm not able to run the encode demo:

/ # echo 0 > /sys/devices/platform/vpss/graphics0/enabled

/ # echo 0 > /sys/devices/platform/vpss/graphics1/enabled

/ # echo 0 > /sys/devices/platform/vpss/graphics2/enabled

/ # ./omx/capture_encode_a8host_debug.xv5T -o sample.h264 -m 720 -f 60 -b 1000000 -n 1000

output file: sample.h264

bit_rate: 1000000

frame_rate: 60

num_frames: 1000

mode: 720

Capture-Encode example

===============================

OMX_Init completed

UIAClient is ready to send a UIA configuration command

UIAClient received UIA_CONFIGURE_ACK

UIAClient is done sending requests

UIAClient is ready to send a UIA configuration command

UIAClient received UIA_CONFIGURE_ACK

UIAClient is done sending requests

openeing file

capture compoenent is created

control TVP compoenent is created

Buffer Size computed: 0

set input port params (width = 0, height = 0)enable capture output port

got eventEnable/Disable Event

dei compoenent is created

set input port params (width = 0, height = 0)

set output port params (width = 0, height = 0)set output port params (width = 0, height = 0)set number of channelsset input resolutionset output resolutionenable dei input port

got eventEnable/Disable Event

enable dei output port 0

got eventEnable/Disable Event

enable dei output port 1

got eventEnable/Disable Event

encoder compoenent is created

found handle 0x122048 for component OMX.TI.VPSSM3.VFDC

got display handle

found handle 0x125b50 for component OMX.TI.VPSSM3.CTRL.DC

Buffer Size computed: 0

set input port params (width = 0, height = 0)setting input and output memory type to defaultenable input port

got eventEnable/Disable Event

connect call for capture-Dei

connect call for dei- encoder

connect call for dei-display

This is the output when I load the firmware into the VPSS:

MemCfg: DCMM (Dynamically ConfigNameServer Module already initialized!

urable Memory MaSharedRegion Module already initialized!

p) Version : 2.GateMP Module already initialized!

1.1.1

MessageQ Module already initialized!

HeapBufMP Module already initialized!

HeapMemMP Module already initialized!

ListMP Module already initialized!

ClientNotifyMgr Module already initialized!

FrameQBufMgr Module already initialized!

FrameQ Module already initialized!

ProcMgr_getProcInfo: bootMode: [0]

MemoryOS_map: pa=0x48180000, va=0xfa180000, sz=0x2fff

MemoryOS_map: pa=0x55080000, va=0xf9080000, sz=0xfff

MemoryOS_map: pa=0x55020000, va=0xf9020000, sz=0x8

DM8168VPSSM3PROC_attach: Mapping memory regions

MemoryOS_map: pa=0x55020004, va=0xf9020004, sz=0x4

MemoryOS_map: entry already exists

mapInfo->src [0x48180000]

mapInfo->dst [0xfa180000]

mapInfo->size [0x2fff]

DM8168VPSSM3PROC_attach: slave is now in reset

MemoryOS_map: entry already exists

mapInfo->src [0x55020000]

mapInfo->dst [0xf9020000]

mapInfo->size [0x4000]

MemoryOS_map: pa=0x55024000, va=0xf9024000, sz=0x3c000

MemoryOS_map: pa=0x40300000, va=0xd4e80000, sz=0x40000

_ProcMgr_map for SlaveVirt:

dstAddr [0x300000]

sgList.paddr [0x40300000]

sgList.offset [0x0]

sgList.size [0x40000]

DM8168VPSSM3PROC_map: found static entry: [2] sva=0x300000, mpa=0x40300000 size=0x40000

MemoryOS_map: pa=0x40400000, va=0xd4f00000, sz=0x40000

_ProcMgr_map for SlaveVirt:

dstAddr [0x400000]

sgList.paddr [0x40400000]

sgList.offset [0x0]

sgList.size [0x40000]

DM8168VPSSM3PROC_map: found static entry: [3] sva=0x400000, mpa=0x40400000 size=0x40000

ProcMgr_getProcInfo: bootMode: [0]

DLOAD: ELF: ELF

DLOAD: ELF file header entry point: 9f5ce2c5

DM8168VPSSM3PROC_translate: translated [0] srcAddr=0x0 --> dstAddr=0x55020000

ElfLoaderTrgWrite_copy: translated 0x0 (sva) --> 0x55020000 (mpa)

MemoryOS_map: entry already exists

mapInfo->src [0x55020000]

mapInfo->dst [0xf9020000]

mapInfo->size [0x3c]

_ProcMgr_map for SlaveVirt:

dstAddr [0x0]

sgList.paddr [0x55020000]

sgList.offset [0x0]

sgList.size [0x3c]

DM8168VPSSM3PROC_map: found static entry: [0] sva=0x0, mpa=0x55020000 size=0x4000

DM8168VPSSM3PROC_translate: translated [0] srcAddr=0x7f0 --> dstAddr=0x550207f0

ElfLoaderTrgWrite_copy: translated 0x7f0 (sva) --> 0x550207f0 (mpa)

MemoryOS_map: pa=0x550207f0, va=0xf90207f0, sz=0x10

_ProcMgr_map for SlaveVirt:

dstAddr [0x0]

sgList.paddr [0x55020000]

sgList.offset [0x7f0]

sgList.size [0x800]

DM8168VPSSM3PROC_map: found static entry: [0] sva=0x0, mpa=0x55020000 size=0x4000

DM8168VPSSM3PROC_translate: translated [0] srcAddr=0x800 --> dstAddr=0x55020800

ElfLoaderTrgWrite_copy: translated 0x800 (sva) --> 0x55020800 (mpa)

MemoryOS_map: pa=0x55020800, va=0xf9020800, sz=0x140

_ProcMgr_map for SlaveVirt:

dstAddr [0x0]

sgList.paddr [0x55020000]

sgList.offset [0x800]

sgList.size [0x940]

DM8168VPSSM3PROC_map: found static entry: [0] sva=0x0, mpa=0x55020000 size=0x4000

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9e700000 --> dstAddr=0x9e700000

ElfLoaderTrgWrite_copy: translated 0x9e700000 (sva) --> 0x9e700000 (mpa)

MemoryOS_map: pa=0x9e700000, va=0xd7000000, sz=0xa1e0c8

_ProcMgr_map for SlaveVirt:

dstAddr [0x9e700000]

sgList.paddr [0x9e700000]

sgList.offset [0x0]

sgList.size [0xa1e0c8]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f11e0c8 --> dstAddr=0x9f11e0c8

ElfLoaderTrgWrite_copy: translated 0x9f11e0c8 (sva) --> 0x9f11e0c8 (mpa)

MemoryOS_map: pa=0x9f11e0c8, va=0xd4ec80c8, sz=0x1f38

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f11e000]

sgList.paddr [0x9f11e000]

sgList.offset [0xc8]

sgList.size [0x2000]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f120000 --> dstAddr=0x9f120000

ElfLoaderTrgWrite_copy: translated 0x9f120000 (sva) --> 0x9f120000 (mpa)

MemoryOS_map: pa=0x9f120000, va=0xd6600000, sz=0x17ea0e

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f120000]

sgList.paddr [0x9f120000]

sgList.offset [0x0]

sgList.size [0x17ea0e]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f29ea10 --> dstAddr=0x9f29ea10

ElfLoaderTrgWrite_copy: translated 0x9f29ea10 (sva) --> 0x9f29ea10 (mpa)

MemoryOS_map: pa=0x9f29ea10, va=0xd4ed0a10, sz=0x30

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f29e000]

sgList.paddr [0x9f29e000]

sgList.offset [0xa10]

sgList.size [0xa40]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f29ea40 --> dstAddr=0x9f29ea40

ElfLoaderTrgWrite_copy: translated 0x9f29ea40 (sva) --> 0x9f29ea40 (mpa)

MemoryOS_map: pa=0x9f29ea40, va=0xd6500a40, sz=0xc1800

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f29e000]

sgList.paddr [0x9f29e000]

sgList.offset [0xa40]

sgList.size [0xc2240]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f360240 --> dstAddr=0x9f360240

ElfLoaderTrgWrite_copy: translated 0x9f360240 (sva) --> 0x9f360240 (mpa)

MemoryOS_map: pa=0x9f360240, va=0xd4ee0240, sz=0xd079

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f360000]

sgList.paddr [0x9f360000]

sgList.offset [0x240]

sgList.size [0xd2b9]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f36d2bc --> dstAddr=0x9f36d2bc

ElfLoaderTrgWrite_copy: translated 0x9f36d2bc (sva) --> 0x9f36d2bc (mpa)

MemoryOS_map: pa=0x9f36d2bc, va=0xd4ef02bc, sz=0x4000

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f36d000]

sgList.paddr [0x9f36d000]

sgList.offset [0x2bc]

sgList.size [0x42bc]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f371300 --> dstAddr=0x9f371300

ElfLoaderTrgWrite_copy: translated 0x9f371300 (sva) --> 0x9f371300 (mpa)

MemoryOS_map: pa=0x9f371300, va=0xd4ef8300, sz=0x34

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f371000]

sgList.paddr [0x9f371000]

sgList.offset [0x300]

sgList.size [0x334]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f500000 --> dstAddr=0x9f500000

ElfLoaderTrgWrite_copy: translated 0x9f500000 (sva) --> 0x9f500000 (mpa)

MemoryOS_map: pa=0x9f500000, va=0xd6800000, sz=0xd3afa

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f500000]

sgList.paddr [0x9f500000]

sgList.offset [0x0]

sgList.size [0xd3afa]

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f5d3afc --> dstAddr=0x9f5d3afc

ElfLoaderTrgWrite_copy: translated 0x9f5d3afc (sva) --> 0x9f5d3afc (mpa)

MemoryOS_map: pa=0x9f5d3afc, va=0xd4f42afc, sz=0x200

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f5d3000]

sgList.paddr [0x9f5d3000]

sgList.offset [0xafc]

sgList.size [0xcfc]

DM8168VPSSM3PROC_translate: (default) srcAddr=0xbfd00000 --> dstAddr=0xbfd00000

ElfLoaderTrgWrite_copy: translated 0xbfd00000 (sva) --> 0xbfd00000 (mpa)

MemoryOS_map: pa=0xbfd00000, va=0xd6a00000, sz=0x168ec0

_ProcMgr_map for SlaveVirt:

dstAddr [0xbfd00000]

sgList.paddr [0xbfd00000]

sgList.offset [0x0]

sgList.size [0x168ec0]

DM8168VPSSM3PROC_translate: (default) srcAddr=0xbfe69000 --> dstAddr=0xbfe69000

ElfLoaderTrgWrite_copy: translated 0xbfe69000 (sva) --> 0xbfe69000 (mpa)

MemoryOS_map: pa=0xbfe69000, va=0xd4f60000, sz=0xf060

_ProcMgr_map for SlaveVirt:

dstAddr [0xbfe69000]

sgList.paddr [0xbfe69000]

sgList.offset [0x0]

sgList.size [0xf060]

DM8168VPSSM3PROC_translate: (default) srcAddr=0xbfe78200 --> dstAddr=0xbfe78200

ElfLoaderTrgWrite_copy: translated 0xbfe78200 (sva) --> 0xbfe78200 (mpa)

MemoryOS_map: pa=0xbfe78200, va=0xd4f80200, sz=0x16c20

_ProcMgr_map for SlaveVirt:

dstAddr [0xbfe78000]

sgList.paddr [0xbfe78000]

sgList.offset [0x200]

sgList.size [0x16e20]

ElfLoader_getSymbolAddress: symName [_Ipc_ResetVector]

ProcMgr_translateAddr: srcAddr [0x9f371300] dstAddr [0x9f371300]

ProcMgr_translateAddr: srcAddr [0x9f371300] dstAddr [0xd4ef8300]

ProcMgr_translateAddr: srcAddr [0x9f37131c] dstAddr [0x9f37131c]

ProcMgr_translateAddr: srcAddr [0x9f37131c] dstAddr [0xd4ef831c]

handle->slaveSRCfg [0].entryBase 9f700000

DM8168VPSSM3PROC_translate: (default) srcAddr=0x9f700000 --> dstAddr=0x9f700000

Platform_loadCallback:

No SharedRegion.entry[0].cacheEnable configuration value found, using default FALSE

Platform_loadCallback:

Mapping SharedRegion 0

addr [ProcMgr_AddrType_MasterPhys] [0x9f700000]

addr [ProcMgr_AddrType_SlaveVirt] [0x9f700000]

size [0x200000]

isCached [0]

MemoryOS_map: pa=0x9f700000, va=0xd6c00000, sz=0x200000

_ProcMgr_map for SlaveVirt:

dstAddr [0x9f700000]

sgList.paddr [0x9f700000]

sgList.offset [0x0]

sgList.size [0x200000]

ProcMgr_translateAddr: srcAddr [0x9f371300] dstAddr [0x9f371300]

ProcMgr_translateAddr: srcAddr [0x9f371300] dstAddr [0xd4ef8300]

DM8168VPSSM3PROC_start: Configuring boot register

Reset vector [0x9f5ce2c5]!

DM8168VPSSM3PROC_start: Slave successfully started!

Ipc_attach: Ipc_procSyncStart failed!

..... More of these messages

Ipc_attach: Ipc_procSyncStart failed!

NameServer_getLocal name [uiaMaster]

NameServer_getLocal: Entry not found!

Notify: Termination packet

FIRMWARE: 2 start Successful

If you have some ideas about what could be wrong with this they will be really appreciated...
Thanks

over 14 years ago

0 Archith John Bency over 14 years ago

TI__Intellectual 2910 points

David,

We have done some basic testing with the latest SDK 5.02.01.59 (http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/index_FDS.html) where we have seen that either of the firmware load within seconds (10 mins is not expected) without connecting a EIO card. i.e just the EVM. Is it possible for you to try this EZSDK with the Z3 PCB?

David Soto said:
firmware_loader 2 /lib/firmware/dm816x_hdvpss.xem3 start /lib/firmware/mm_dm81xxbm.bin (5 to 10minutes to load the firmware)
firmware_loader 1 /lib/firmware/dm816x_hdvicp.xem3 start /lib/firmware/mm_dm81xxbm.bin (less than 10sec to load the firmware)

Can you confirm that you can see the issue if you dont supply a .bin file to the firmware loader? Let the firmware loader use the default Mem Map as in the EZSDK. I am assuming Z3 HW has 1GB DDR memory. If it has 512MB, the following wiki entry is of interest. http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Changing_Memory_Map_For_512MB_Board

Does the Z3 HW use TVP7002? TVP7002 is the only capture device supported currently in the current EZSDK. I am suspecting that either TVP7002 is not used with Z3 HW or if it is, it's not located at the same I2C slave address as in the case of TI EVM + EIO card setup.

David Soto said:

found handle 0x125b50 for component OMX.TI.VPSSM3.CTRL.DC

Buffer Size computed: 0

set input port params (width = 0, height = 0)setting input and output memory type to defaultenable input port

got eventEnable/Disable Event

connect call for capture-Dei

connect call for dei- encoder

connect call for dei-display

To get more details about the hang here, you can have a look at traces from the vpss firmware. Below is the command to use (via a tenet session to the board) once the crash/hang has occured:

#/usr/share/ti/ti-uia/loggerSMDump.out 0x9E400000 vpss

(If you want ot try this out on the EZSDK version 5.02.00.57, change the hex value above to 0x9E100000 )

Archith

0 David Soto - RidgeRun over 14 years ago in reply to Archith John Bency

Genius 3700 points

Hi Archith,

Thanks for your reply.

Archith said:
We have done some basic testing with the latest SDK 5.02.01.59 (http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/index_FDS.html) where we have seen that either of the firmware load within seconds (10 mins is not expected) without connecting a EIO card. i.e just the EVM. Is it possible for you to try this EZSDK with the Z3 PCB?

Now I'm using the latest EZSDK 5.02.01.59 and the same error is seen with this new version, it takes around 5 or 10 minutes to load the firmware into the VPSS. Then, as you suggested I decided to try with the default memory map but this didn't solve the problem, it shouldn't be a problem since the Z3 module has 1GB DDR memory

Archith said:
Does the Z3 HW use TVP7002? TVP7002 is the only capture device supported currently in the current EZSDK. I am suspecting that either TVP7002 is not used with Z3 HW or if it is, it's not located at the same I2C slave address as in the case of TI EVM + EIO card setup.

.

I checked the Z3 hardware and it has a TVP7002 as well. Seems that the problem is related with some I2C address as you pointed out. I didn't have this problem with the firmware that was released with the EZSDK version 5.01.01.80, but with that version I hadn't been able to test the capture-encode demo since it didn't include it.

If it is a problem with some i2c address, Can you give a clue how to solve it? since TI didn't provide the code for the firmware?

Thanks in advance,

David

0 Ed Langley over 14 years ago in reply to David Soto - RidgeRun

Prodigy 50 points

Hi David

I have the same setup as you (SDK 5.02.01.59, Z3-DM8168 module and application base board) and I am seeing exactly the same problems as you. Have you got anywhere with this so far?

Archith, I'd really like to get the capture_encode demo working with the Z3 board. The message from TI on these forums seems to be that the VPSS firmware is a "black box" which we shouldn't concern ourselves with. Do you know for sure that this FW is accessing the TVP7002 over I2C?

If the VPSS FW is accessing encoders over I2C, and it is a black box, then how are customers supposed to produce custom boards with the DM8168, since the choice of encoder and which I2C bus to connect it to is certainly board specific, as we are seeing with the Z3 module.

Is there a way to turn the TVP7002 initialisation in the VPSS firmware off without changing the FW?

Thanks

0 Archith John Bency over 14 years ago in reply to Ed Langley

TI__Intellectual 2910 points

Ed,

Ed Langley said:
Do you know for sure that this FW is accessing the TVP7002 over I2C?

The FW does access the TVP 7002 over I2C.

Ed Langley said:
If the VPSS FW is accessing encoders over I2C, and it is a black box, then how are customers supposed to produce custom boards with the DM8168, since the choice of encoder and which I2C bus to connect it to is certainly board specific, as we are seeing with the Z3 module.

To address this, TI is planning to provide drivers on Linux/A8 to configure video decoders like TVP7002. This would mean that the configuration of I2C responsible for communications with video decoders is via Linux drivers. This is planned to be available sometime in a Linux PSP drop sometime in 4Q11. Also, one should be able to write Linux drivers for the different video decoders on the custom boards.

Ed Langley said:
Is there a way to turn the TVP7002 initialisation in the VPSS firmware off without changing the FW?

In the present SDK, we don't have a way of doing this.

Thanks for pulling these important points up.

David, Ed,

To look at the matter at hand, have you tried what I suggested here:

Archith said:

To get more details about the hang here, you can have a look at traces from the vpss firmware. Below is the command to use (via a tenet session to the board) once the crash/hang has occured:

#/usr/share/ti/ti-uia/loggerSMDump.out 0x9E400000 vpss

(If you want ot try this out on the EZSDK version 5.02.00.57, change the hex value above to 0x9E100000 )

0 Ed Langley over 14 years ago in reply to Archith John Bency

Prodigy 50 points

Hi Archith,

The last few lines of the log after running:

#/usr/share/ti/ti-uia/loggerSMDump.out 0x9E400000 vpss

are:

N:VPSS P:2 #:00683 T:0000015b|d72bb0eb S:Module<OMX.TI.VPSSM3.CTRL.TVP> Entering<OMX_BASE_SendCommand> @line<472>
N:VPSS P:2 #:00684 T:0000015b|d72c5f11 S:Module<OMX.TI.VPSSM3.CTRL.TVP> Leaving<OMX_BASE_SendCommand> @line<638> with error<0:ErrorNone>
N:VPSS P:2 #:00685 T:0000015b|d72d6395 S:Module<OMX.TI.VPSSM3.CTRL.TVP> Entering<OMX_BASE_CmdEventHandler> @line<437>
N:VPSS P:2 #:00686 T:0000015b|d72dfc81 S:Module<OMX.TI.VPSSM3.CTRL.TVP> Entering<OMX_BASE_PROCESS_CmdEvent> @line<528>
N:VPSS P:2 #:00687 T:0000015b|d72e526f S:Module<OMX.TI.VPSSM3.CTRL.TVP> @<OMX_BASE_PROCESS_CmdEvent> @line<540> msg<Processing OMX_CommandStateSet>
N:VPSS P:2 #:00688 T:0000015b|e6170143 S: CAPTUREAPP: VIP 0: VID DEC 0401 (0x5d): 7002:0000:0000

Given that 0x5d is the I2C address of one of the TVP7002 decoders, the last line looks relevant.

Thanks

0 Archith John Bency over 14 years ago in reply to Ed Langley

TI__Intellectual 2910 points

Ed,

When I run a capture application on TI EVM+ Expansion card setup, I see that the corresponding status message is

CAPTUREAPP: VIP 0: VID DEC 0401 (0x5d): 7002:0002:0000

0x5d is indeed the I2C address of the TVP 7002 chip and this seems to be to that on the TI EVM.

The only difference is 0002 which is actually the decoder chip version. It seems that that the Firmware is trying to set the Video Mode on the decoder chip but has got stuck in this function.

I will discuss this internally and get back you next week.

Archith

0 Archith John Bency over 14 years ago in reply to Archith John Bency

TI__Intellectual 2910 points

Returning to this thread, having a different version of the TVP7002 (from that on the TI EVM) is not supported currently. Having the ability to program video decoders via Linux/A8 should resolve this problem.

Archith

Processors

Processors forum

Hang-up issue loading dm816x_hdvpss.xem3 firmware