This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EVMK2G: HDMI output from the DSP core

Part Number: EVMK2G

Hi,

My initial idea of using K2G EVM with CMB was to acquire the data from the CMB, process them on the DSP core and pass them to ARM for display through the HDMI output (e2e.ti.com/.../754234). This video signal will have to be wirelessly transmitted to a receiving PC. Analysing the SDK example code for all three parts I realised IPC communication and integration with the other parts of code is too much to meet our deadline. Therefore I thought of, at least initially, doing everything on the DSP core.

  1. Can I boot the DSP core directly from the SD card and load my application code?
  2. Does the bootloader configure everything for the DSP to run with CMB and HDMI?
  3. Can I use HDMI together with CMB? I am asking this in case there are some pin muxing incompatibilities (of the kind like not being able to use HDMI with the PRU cape on the Beaglebone Black)
  4. I noticed there is an example for HDMI under c:\ti\pdk_k2g_1_0_10\packages\ti\board\diagçhdmi. I was able to build hdmi_diagExample_evmK2G_armv7.out using gmake LIMIT_BOARDS="evmK2G" LIMIT_SOCS="k2g" LIMIT_CORES="dsp_0" board_diag. This "_armv7" extension is confusing. Is that DSP executable?
  5. HDMI was my first choice because it looked straightforward. Now I am not so sure. Can I get the data out of the EVM through Ethernet using the TI RTOS? I imagine the simplest way would be to use Ethernet connecting through WiFi to the receiving PC (50-100 metres away with line of sight), is this doable wit TI-RTOS? Is there any example of using Ethernet on K2G EVM?

Thank you and best regards,

Adam

  • Adam, thanks for considering our devices. Our response may be delayed due the holidays.
  • Adam,

    Yes, DSP core can directtly be booted from SD card and load your application code using the secondary bootloader that is provided in processor SDK Rtos.

    The device boots the ARM first using the secondary bootloader which you don`t need to modify. To convert your .out application to bootable image, you can convert .out to .rprc image and the multi-core application using the tools out2rprc and MulticoreImageGen. this is pretty straight forward once you have the application tested over emulator.  Let us know if you run into any issues.

    The bootloader only does configuration of K2G system clocks, pinmux for base EVM and DDR configuration and wake up slave cores if required which should be sufficient for the HDMI test. The CMB application code has the additional pinmux changes and the multi channel audio processing. you need to ensure that there is no pinmux conflicts between MCASP and HDMI/DSS pins so that when CMB pinmuxing is applied. We provide a pinmux tool to check such conflicts.

    you can import the baseline pinmux project from .pinmux file found in location pdk_am57xx_1_0_xx\packages\ti\board\src\evmK2G. In the pinmux tool select the correct device and import the baseline pinmux to see the default setup  and then confirm that there is no conflict between MCASP And display subsystem.

    I did a quick spot check and didn`t see any conflicts. Infact there are three instances of MCASP with one instance name suggesting it accounts for the HDMI usecase but I suggest that you check this out.

    The HDMI, diagnostic application is a test application used by TI/board manufacturer to test the baseline HW to checkout HDMI functionality. This is an ARM A15 based test that checks out that color bars show up on the HDMI display as expected before the board is shipped for development to customers.

    This is provided in the package so users can use it as reference or modify it to test their own HW or verify that the EVM that they are using works as expected.

    Ethernet functionality on K2G is enabled using a network stack called NDK. The stack requires NIMU driver from PDK package. It can be used to create a HTML like front end display if required as has been demonstrated using the Image Processing demo in Processor SDK RTOS:

    Hope this provides you enough insight to get started with this effort.

    Regards,

    Rahul

  • Dear Rahul,

    Thank you very much for your detailed answer. From what I understand you mean that first we need to boot the ARM core, which in turn loads the DSP firmware, however this is not what we want. Our objective is to use the DSP core _only_ (for both CMB and HDMI) to avoid having to move data between the ARM and the DSP (development time constraints).

    From software-dl.ti.com/.../index_overview.html I understand that we can create DSP firmware using CCS and the emulator and make it into an application image, create and SD card and boot the DSP directly just with that application (and the MLO).

    We would like to be able to control HDMI directly from the DSP, but we can't find any example.

    Our intended workflow is to develop the entire application (CMB+HDMI) using the CCS and the emulator, make it into an application image and run from the SD card.

    Does the MLO bootloader configure everything for the DSP to run with CMB and HDMI?

    If using HDMI is not possible, can we use Ethernet directly from the DSP? If not, what is the easiest way to get the data out of the DSP? We need to get the processed data somehow out of the K2G EVM the simplest possible way.

    Best regards,

    Adam
  • Adam,

    The MLO bootloader is designed to configure the SOC and be able to run application on the base EVM. The clock, pinmux settings done by the MLO bootloader is limited for the base board and for multicore application boot. This should already account for the onboard HDMI but, for CMB usage the CMB Application needs to apply the additional pinmux for using the additional McASP pins.

    this is currently done in the CMB demo that we provide but for your application board, you can generate the pinmux using TI Pinmux tool and drop the generated files into board and rebuild so the bootloader applies the setting at the time of boot.

    Yes. ethernet can be used directly from the DSP we provide a network development stack called NDK that sits on top of the NIMU transport driver and ethernet driver.

    software-dl.ti.com/.../index_Foundational_Components.html

    Currently in absence of a display/HDMI driver, ethernet may be a better option. The other alternative is to design with AM572x or AM571x which has the MCASPs and the display driver support for such a design. However the CMB demo will need to be ported as the TI EVM/IDK hardware doesn`t bring out all the MCASP pins as the K2G EVM does.

    Regards,
    Rahul