All,
We're seeing problems when attempting to load the dm816xbm_m3video.xem3 and dm816xbm_m3vpss.xem3
images onto the CortexM3s of an 8168 processor. We've been perusing the forums and have seen similar problems
reported by others but the problems/solutions don't quite match what we're seeing.
UPDATE:
Just came across another post on the forum where it was mentioned that the
ti-ezsdk_dm816x-evm_5_01_01_80 SDK does *not* allow for changes in the memory map
which would impact the CortexM3 functionality if boards have less than 1GB of memory.
Can anyone confirm this? If that's true, is this being planned for the next SDK release (Aug?)
to allow for alternatives to the fixed memory map? How will this be addressed for the *.xem3
f/w images if that code will be closed-source (the video subsystem code)?
Specifically, we've built our Syslink drivers/apps and gotten our *.xem3 images from the ti-ezsdk_dm816x-evm_5_01_01_80
and have been able to get the *.xem3 images loaded on a C6A816x evaluation module from Spectrum Digital (the DDR2 model)
successfully. Though we can't run the full blown OmxInit examples on the older EVM we were able to at least load the M3s of
the C6A816x and insmod the relevant drivers (vpss.ko, ti81xxfb.ko, and TI81xx_hdmi.ko) with no problems so that we
could light up the frame buffers at the linux level (/dev/fb0,/dev/fb1,/devfb2) and check out the OnChip-HDMI.
When we use these same binaries on an alpha board using an actual 8168 (not the C6A816x) the procmgrapp
hangs and won't continue or allow itself to be Control-Z'ed so we can't continue to work with the console. It hangs
on the Ipc_control(...) call when procmgrapp attempts to do the STARTCALLBACK.
# ./procmgrapp_debug 1 dm816xbm_m3video.xem3 0
ProcMgrApp sample application
Entered SysLinkSamples_startup
SysLinkSamples_osStartup
Entered ProcMgrApp_startup
ProcMgr_attach status: [0x0]
After attach: ProcMgr_getState
state [0x1]
ProcMgr_load status: [0x3046000]
After Ipc_loadcallback: ProcMgr_getState
state [0x3]
ProcMgr_start passed [0x6a85000]
#### hangs ....
We are using the recommended Code Sourcery Tool chain and don't encounter this problem with procmgrapp
when we attempt to load the DSP [we used the EZSDK syslink rtos samples to get an *.xe674 image for
comparison testing and the test ran fine].
So far it seems to be only an issue with loading the M3s on an 8168 and not with the other cores or on the
C6A816x.
Are there additional registers (PRCM/CLKs/etc) that need to be turned on if we're on an actual 8168 that
are being ignored on a C6A816x platform to load the M3s? We're not trying to do anything fancy yet
(captures, encoding, etc) so we didn't expect to have differences yet for this range of board checkout/testing.
We've also tried using the Ducati() GEL file script from the Ti816x_ddr.gel file (and other related menu items) to
see if we could "poke it along" just in case we missed something but that didn't help.
Any thoughts or suggestions? Is anybody else seeing this flavor of the problem [where even the Control-Z
workaround didn't work]?
Thanks in advance for any insight.
- Juan
