RTOS/AM5728: Bare-metal support

Bob,

I can attempt to respond to the customers questions/concerns regarding RTOS software and have looped in my colleagues who are device and board design experts to respond to the question regarding OPP and DDR.

Bob Bacon said:

• SW RTOS issues on EVM board –  Unfortunately, the EVM is not good solution, because it is primarily targeted to show Sitara capabilities with Linux and LCD display. This leads to limitations in peripherals and availability of interfaces. For our purposes, we need two dedicated interfaces for sample exchange between Sitara and RF FE, but due to configuration we must use SPI 3 and SPI4. Observed issues:

1. 1. Too many abstraction layers between RTOS and HW http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_Software_Stack
   2. No straightforward way to use LLD and scheduler component from TI RTOS only
   3. SPI LLD drivers does not support all modes on all interfaces – there are no DMA channels available for SPI3 and SPI4 (need to check latest status/version). Difficult configuration of DMA cross connect.
   4. SPI slave mode not fully supported
   5. Scripted builds of RTOS (XDC tools) lead to dead code included
   6. Multi platform/multi device support of RTOS – lot of conditional compilation combined with scripts provide mess

The processor module was initially designed to be a community development board that was low cost and provided enough functionality to test several multi-media features like LCD/ camera interfaces and connectivity features of the SOC. If you usecase is more industrial application that uses ICSS subsystem then this is not the right platform for evaluation. AM572x/AM571x IDK is better suited for your evaluation.

We strongly recommend that the customer review our training presentation on Application development with Processor SDK RTOS to understand the RTOS SDK software development methodology and also to see the benifits of using this model The LLD drivers are designed to operate in an TI RTOS and bare-metal environment through implementation of OS abstraction layer (OSAL)  that allows user to choose between using TI RTOS as you can see using the LLD driver examples or do bare-metal development as you can see in the EVM diagnostics.

We do agree with the feedback that since  SDK is designed for multiplatform support, there is lot of conditional compilation but this is the only way TI can scale the software across multiple product lines. There is an initiative to improve the user experience with more examples specific to targets but this is work in progress and will show up in 2018.

Bob Bacon said:

• SPI LLD drivers does not support all modes on all interfaces – there are no DMA channels available for SPI3 and SPI4 (need to check latest status/version). Difficult configuration of DMA cross connect.
• SPI slave mode not fully supported
• Scripted builds of RTOS (XDC tools) lead to dead code included

SPI LLD can be tested only using interfaces available on the evaluation platform. For extended functionality like SPI3 and SPI4 if you see the SPI LLD soc setup inside (SPI_soc.h), you will see that the interrupt setup is already provided, setting up the DMA cross bar and DMA resources is considered responsibility of the application developer/system integrator. We do have examples of SPI LLD with DMA enabled but can provide complete feature set due to limitations of features available on the EVM.  Can you indicate what features in the SPI slave implementation that the customer needs for their application. We can file new feature requests to enable addtional features.

The current SPI LLD slave implementation and examples are provided here:

http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_QSPI-McSPI

The full API reference guide is inside the SDK at location pdk_am57xx_1_x_x\packages

Bob Bacon said:

SW RTOS on IDK – better supprot from RTOS side, but not suitable for current project prototype. Can be used for PRUSS evaluation, but from examples seems that RTOS/Linux is required http://processors.wiki.ti.com/index.php/PRU-ICSS_Ethernet (not evaluated)

Can you provide more specific feedback on what features are not available on the IDK that you want us to add ? If the customer doesn`t want to use RTOS, they can look  at the simpler bare-metal EVM diagnostics or CSL-FL examples in the package and let us know what features we can add to enable their development.

Bob Bacon said:

Bare metal – currently we don’t have way to use LLD only and scheduler from RTOS

All of the PDK examples are  using LLD drivers that are using bare-metal functional CSL code and only using specific module in TI RTOS like HWI, semaphores, HEAP, etc.  the other components like SBL, board library etc have no dependency on RTOS and can be used from bare-metal as well as RTOS.

Regards,

Rahul