CCS/DRA75: Examples showing error on uart console

Hi Sam,

I would suggest you start with the IPC example configuration files for messageq_single under packages/ti/ipc/tests (see rpmsg_transport.cfg, IpcCommon_vayu.cfg.xs, IpuAmmu_vayu.cfg and Ipu1Smp.cfg), or the examples/DRA7XX_linux_elf/ex02_messageq test app.  You can check if loading is successful with these first and then use that as a reference for bringing in the IPC hooks into the PDK example app.

Here is a good article on resource table customization for when you are to that point, and may need to override the default: http://processors.wiki.ti.com/index.php/IPC_Resource_customTable

Lastly, I would be careful with integrating any of the PDK examples since they all make use of the UART console.  This is fine when running in an RTOS-only environment, but when integrating under u-boot/Linux, you will have a resource conflict.  I suggest you remove UART prints from your IPU application and use IPC trace to print messages back to the Linux remoteproc trace buffer.

Thanks,
Stephen

Hi Sam,

I assume you mean something observable besides UART console?  Here are a few options I can think of:

• There is an audio loopback example which will pass audio from Line In port back to Line Out port.  
• EMAC basic example will do loopback at the PHY level, so you should see activity indicator lights on the Ethernet 0 port
• NIMU basic example will give you IP connectivity and you can see lights on either Ethernet port upon active connection

Otherwise, there is a board LED blink example which is used by other device families which share the same EVM layout.  It is not a supported example for this device but I could give details on how to bring this up if the above are not sufficient.

Thanks,
Stephen

Hi Sam,

I'm not familiar with DFU - Does the output you show on the console indicate that you are now able to load IPU1 binary?

The PDK peripheral/stack examples are designed to run in a standalone RTOS environment.  The examples handle all platform initialization and don't care about sharing resources with other CPUs on the SOC because they are intended to demonstrate everything needed to make the peripheral work in that environment.

When porting to run alongside another OS on another CPU, there will be modifications required to free any conflicts in resource management.

• The example needs to remove access to any peripheral ports used by u-boot.  For instance, UART console, I2Cs, etc.
• Pad configuration needs to be removed from the application and put into u-boot.  There are two steps:
  • Remove pad config code from the NIMU app.  See the following link on how to do this: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/04_03_00_05/rtos/Board_EVM_Abstration.html#board-support -> Considerations for DRA7xx devices
  • Add the necessary entries into dra74x_core_padconf_array and dra742_es?_?_iodelay_cfg_array

Hope this helps clear things up.  Otherwise, maybe it would be more helpful if you told me what your end goal is so we don't spend a lot of time on experiments which will just be throwaway.

Thanks,
Stephen

Hi Sam,

What is your target application going to look like?  Do you need Linux to run on A15 or is this going to be a pure RTOS system?  Can you give any other info about the type of application, just so I can make sure you are using the best fit SDK?

If you don't need Linux, then we have an RTOS Secondary Bootloader (SBL) which can boot from SD card and doesn't require any JTAG connectivity.  You can see more details in the <pdk>/packages/ti/boot/sbl_auto and look at the contained doc/SBL_UserGuide.pdf.  This will tell you how to build the SBL for the desired boot method and SoC performance level.  It also gives details on how to convert the ELF binaries for each CPU into a single multi-core AppImage which can be loaded by SBL.  This is the most straightforward way to get some PDK peripheral example running without CCS.

• Note the PDK examples use the board library to enable them to run standalone from CCS.  When migrating to boot from SBL, there some changes needed to remove conflicting/duplicating platform code.  Please see http://software-dl.ti.com/processor-sdk-rtos/esd/docs/04_03_00_05/rtos/Board_EVM_Abstration.html#considerations-for-dra7xx-devices for more details on this.

If you do need Linux, then the RTOS SBL will only be good to test things but won't work in long-term, so we will need to explore other options.

Thanks,
Stephen