• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 98 subscribers
  • Views 488 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TDA4VM: TDA4VM - Heterogenous development

Prasanna Raghunathan
Prodigy 110 points

Part Number: TDA4VM
Other Parts Discussed in Thread: AM2431, SYSCONFIG,

Hi,

I am working on a project to use the A72 and R5 in the main domain for my application. I need guidance on the best way to develop on the R5 and integrate the R5 build process or final FW Binaries into Yocto based on the TI ARAGO SDK. I am clear on the Yocto side of things.

I see several options and I would like expert opinion on the following:

  • Which SDK to use for R5 Development ? 
    • J721E Processor SDK 
    • MCU + SDK for R5 (based on the AM2431 which is exactly the R5 cores on main domain)
  • Target OS
    • A72 - Linux
    • R5 - FreeRTOS or noRTOS
    • Planning to use remoteproc framework to interface the A72 and R5. 
  • TI SYS FW - Board Cfg/RM Cfg/DM Cfg:
    • From the TI ARAGO SDK, I need to somehow customize the pin outs/pin mux and setup peripherals, allocate resources to R5 as well as A72 differently than the EVM reference design. 
    • What is the best approach to get this done ? External TI CCS/sysconfig tool to create the dts files and then pull it into Yocto ? 
    • Currently, I see the pre-built binaries being pulled from git repository and simply being packaged into sysfw.itb. The recipe is "ti-sci-fw.bb" which manages the sysfw. Not sure how to override them yet.

Thanks,

Prasanna

  • 0
    TI__Guru*** 125395 points

    Hi Prasanna,

    Prasanna Raghunathan said:
    Which SDK to use for R5 Development ? 
    • J721E Processor SDK 
    • MCU + SDK for R5 (based on the AM2431 which is exactly the R5 cores on main domain)

    Please use the J721E Processor RTOS SDK for developing RTOS applications for TDA4VM.

    Please note that all the Processor SDKs are released matching a particular device, so you cannot take a AM2431 MCU+SDK and use it with TDA4VM.

    Prasanna Raghunathan said:
    Target OS
    • A72 - Linux
    • R5 - FreeRTOS or noRTOS

    This is all good. MCU R5F needs to run a Device Management (DM) library component, along with your application, and this requires an RTOS like FreeRTOS or SafeRTOS. NoRTOS/Baremetal firmwares can be used for the MAIN R5Fs and can work with Linux.

    Prasanna Raghunathan said:
    What is the best approach to get this done ? External TI CCS/sysconfig tool to create the dts files and then pull it into Yocto ? 

    The CCS/SysConfig can give you the required pinmux device-tree nodes, but it won't generate ready-to-go complete device-tree files. You would have to take these excerpts and incorporate into your board-specific dts file. The TI SDKs do the base device dtsi files that can be included and adjusted in your board dts file.

    All of these changes need to be incorporated into a Linux Kernel tree. Yocto recipes deal with a Linux kernel devicetree, and you can adjust your platform yocto recipes to be able to pull and build for your particular platform.

    Prasanna Raghunathan said:
    Currently, I see the pre-built binaries being pulled from git repository and simply being packaged into sysfw.itb. The recipe is "ti-sci-fw.bb" which manages the sysfw. Not sure how to override them yet

    The firmware integration into Yocto is through the ti-linux-firmware repository. The TI SDKs build using a default DM firmware built for the EVM, but you will need to incorporate your own firmware for your board.

    It is up-to-your recipes on how you stage and pull in the firmwares and utilize them.

    regards

    Suman

  • 0 in reply to Suman Anna
    Prodigy 110 points

    Hi Suman,

    Thanks for your response.  Here is my understanding so far of the high level flow:

    1. Use the processor RTOS SDK which comes with the ti-cgt-armllvm compiler and build my custom FreeRTOS project for target R5F and get the binary file out. Now this binary file goes into yocto to get packed into Linux image. Now from Linux use remoteproc to load this FW to the R5 target. If this is not true, how to build my FreeRTOS project ? It's better to build this with TI CCS by pulling in the processor SDK or directly use makefiles against the project ?

    2. Use SYSCFG to generate the overall system pin configuration integrate this dtsi excerpt into the K3-R5 Uboot SPL which will setup the pins and peripherals right during boot. This is effectively the tiboot3.bin.

    3. Which FW Component is responsible for assigning required peripherals/interrupts/DMA Channels to A72/R5/DSP Cores.is it DM or sysfw (RM Config and board cfg) ?

    4. SYSFW runs on the DMSC  Cortex - M core. This says the PM Config , RM Config and board config are part of the sysfw. 

    docs.u-boot.org/.../j721e_evm.html

    5. DM -> you're saying there should be a DM instance running with my FreeRTOS project on the MAIN DOMAIN R5 as well. Do you mean to say the SCI-Client to talk to SYSFW running on DMSC ?

    I don't see the source-code in the Processor-SDK-RTOS package. Is there a separate github repo holding the reference design source code for this DM firmware ? This should be built standlone via TI CCS or J721E Processor RTOS SDK or can be compiled via yocto for the K3-R5 target machine ? 

    Please let me know if you have any questions. 

    Thanks,

    Prasanna

  • 0 in reply to Prasanna Raghunathan
    TI__Guru*** 125395 points

    Hi Prasanna,

    Prasanna Raghunathan said:
    Use the processor RTOS SDK which comes with the ti-cgt-armllvm compiler and build my custom FreeRTOS project for target R5F and get the binary file out. Now this binary file goes into yocto to get packed into Linux image. Now from Linux use remoteproc to load this FW to the R5 target.

    Yes correct. The build and development is all based on the RTOS SDK. Yocto does not use the RTOS SDK to build firmwares (as Yocto requires all components to be in a public git tree). The integration/inclusion of the firmware is part of your rootfs creation. You can either do a post-processing copying step, or have a recipe to pull in the desired firmwares into your rootfs, with the firmware out file being made available as part of a git tree.

    Prasanna Raghunathan said:
    It's better to build this with TI CCS by pulling in the processor SDK or directly use makefiles against the project ?

    It is recommended to use the Makefiles. There are many components and layers in the RTOS SDK, that the CCS doesn't understand, and the RTOS SDK is not provided with CCS projects for every example. 

    Prasanna Raghunathan said:
    2. Use SYSCFG to generate the overall system pin configuration integrate this dtsi excerpt into the K3-R5 Uboot SPL which will setup the pins and peripherals right during boot. This is effectively the tiboot3.bin.

    You can use SysConfig to generate the overall pin configuration, but you may have to pick the needed excerpts into the relevant dtsi files manually. It is not going to be a drop-in replacement file, since SysConfig doesn't understand the Linux or U-Boot specific device-tree layout archictecture.

    Please also note that the U-Boot dtsi file paths have changed, there are the upstream pieces inherited/sync from Linux kernel and then there are the U-Boot specific changes.

    Prasanna Raghunathan said:
    3. Which FW Component is responsible for assigning required peripherals/interrupts/DMA Channels to A72/R5/DSP Cores.is it DM or sysfw (RM Config and board cfg) ?

    The MCU1_0 firmware will be running the DM Component, called the SciServer task. The term "SysFW" is used to refer to both the "TIFS" and "DM" pieces. RM Config and Board Config files need to be processed by both the TIFS firmware as well as the MCU1_0 firmware.

    Prasanna Raghunathan said:

    4. SYSFW runs on the DMSC  Cortex - M core. This says the PM Config , RM Config and board config are part of the sysfw. 

    docs.u-boot.org/.../j721e_evm.html

    Please see my above response on #3.

    Prasanna Raghunathan said:
    5. DM -> you're saying there should be a DM instance running with my FreeRTOS project on the MAIN DOMAIN R5 as well. Do you mean to say the SCI-Client to talk to SYSFW running on DMSC ?

    No, DM is needed to run only on the MCU R5F project. The Main R5Fs will need to use a SciClient API interface to request/configure resources from the DM firmware running on MCU R5F.

    Please see the Texas Instruments System Controller Interface (TISCI) section of the TI-SCI documentation that gives you an overview.

    Prasanna Raghunathan said:
    I don't see the source-code in the Processor-SDK-RTOS package. Is there a separate github repo holding the reference design source code for this DM firmware ?

    The Sciclient and SciServer code is part of the PDK SciClient module. PDK does have a git tree as well for reference, but you will be building against the downloaded RTOS SDK which has the PDK component.

    Prasanna Raghunathan said:
     This should be built standlone via TI CCS or J721E Processor RTOS SDK or can be compiled via yocto for the K3-R5 target machine ? 

    I recommend you to look through the RTOS SDK Getting Started sections, and the Developer Guides under the RTOS SDK documentation as well as the PDK documentation.

    regards

    Suman

  • 0 in reply to Suman Anna
    Prodigy 110 points

    Hi Suman,

    I reviewed the SDK docs and played around the PDK especially. This is my understanding so far:

    1. MCU_R5F : sysfw.itb.

    - Peripheral configuration(DMA/Interrupts/SPI) : This is done via boardcfg_rm.c.  This is located under PDK/scicilent. I customize this and recompile the sysfw and integrate into Yocto. This will include all changes for A72/C66/C71x/Main R5. 

    Use k3-resource partition config tool to do this. (Online version). I see a board configuration section here which could be used. 

    This should generate the boardcfg_rm.c and I also see some rm-cfg.yaml cfg files which could be integrated directly into Uboot flow. Please confirm this is true. I don't need the PDK in this case at all and just the use the rm-cfg.yaml.

    - Pinmux : Sysconfig tool to generate the j721e_pinmux_data.c and J721E_pinmux.h files and integrate into PDK to regenerate the sysfw. 

    This also gives a device tree snippet to include to uboot and linux device trees to maintain the gpio configs consistent.

    2. MAIN_R5F : tispl.bin (dm component)

    - Use the RTOS SDK->PDK + Clang tools with makefiles.

    - Compile FreeRTOS project and include sciclient apis to request resources like Interrupts/DMA.

    - No changes to boardcfg here. 

    Thanks,

    Prasanna

  • 0 in reply to Prasanna Raghunathan
    TI__Guru*** 125395 points

    Hi Prasanna,

    1. MCU_R5F: sysfw.itb

    Please note that the sysfw.itb file is an artifact only when using the R5 SPL Bootloader (built from U-Boot source code). This file is irrelevant with RTOS SBL (source code part of PDK). The sysfw.itb file is comprised of the TIFS firmware binary, and all the 4 different Board Configuration files. The RTOS SBL has the TIFS binary as a separate tifs.bin file, with the 4 Board Configuration files part of the SBL (tiboot3.bin) binary itself.

    Prasanna Raghunathan said:
    - Peripheral configuration(DMA/Interrupts/SPI) : This is done via boardcfg_rm.c.  This is located under PDK/scicilent. I customize this and recompile the sysfw and integrate into Yocto. This will include all changes for A72/C66/C71x/Main R5. 

    The boardcfg_rm.c is the RTOS version of the RM board configuration, it merely has the partition data for the common RM resources between the different cores, it will not do the configuration itself when it is processed, that happens at runtime.

    What is the bootloader that you will be using? The PDK boardcfg files are only relevant when using RTOS SBL as your MCU R5F bootloader.

    Prasanna Raghunathan said:

    Use k3-resource partition config tool to do this. (Online version). I see a board configuration section here which could be used. 

    This should generate the boardcfg_rm.c and I also see some rm-cfg.yaml cfg files which could be integrated directly into Uboot flow. Please confirm this is true

    Yes, this is all correct. You can start with an existing syscfg file that can be imported and customized to create the Board configuration files relevant for your platform/product.

    Prasanna Raghunathan said:
    I don't need the PDK in this case at all and just the use the rm-cfg.yaml.

    rm-cfg.yaml file is the U-Boot R5 SPL equivalent file of boardcfg_rm.c, that is compiled into the sysfw.itb file.

    Prasanna Raghunathan said:
    - Pinmux : Sysconfig tool to generate the j721e_pinmux_data.c and J721E_pinmux.h files and integrate into PDK to regenerate the sysfw.

    Mostly correct, though you would regenerate the SBL (tiboot3.bin) and not the sysfw (tifs.bin). The Pinmux Data has no bearing with the TIFS binary.

    2. MAIN_R5F : tispl.bin (dm component)

    tispl.bin is not associated with MAIN_R5F core at all. tispl.bin is again the U-Boot based bootloader binary that will comprise of the A72 ATF, A72 OPTEE, A72 SPL and the DM/application firmware to be booted on the MCU R5F core.

    Prasanna Raghunathan said:
    - Use the RTOS SDK->PDK + Clang tools with makefiles.

    You would use this to build the DM firmware or the MCU R5F application (as well as any MAIN R5F application firmwares).

    Prasanna Raghunathan said:

    - Compile FreeRTOS project and include sciclient apis to request resources like Interrupts/DMA.

    - No changes to boardcfg here.

    These are correct for MAIN R5F firmwares.

    regards

    Suman

  • 0 in reply to Suman Anna
    Prodigy 110 points

    Hi Suman,

    Thanks for your response. I think there is a mixup regarding the Yocto flow (Uboot bootloader) vs RTOS SDK/PDK flow(TI SBL).

    I am using the TI ARAGO SDK to build all the components. I have my own Yocto customizations done for the ARAGO DISTRO. This is why I have been trying to understand the PDK flow and integrate the artifacts back into the Yocto flow.

    Uboot is my preferred Bootloader and I don't want to use the standalone SBL provided from the RTOS SDK.

    Let me address this into two separate sections:

    • MCU R5F -> Uses Uboot SPL as SBL. Looks like I need to pull in the rm-cfg.yaml and integrate it into Uboot flow to generate the tiboot3.bin. This will address the resource management part. Now the pin mux should also be applied to Uboot va the device tree include file from sysconfig. I am already applying the DDR phy cal customizations here.

                This binary should already have a default DM implementation for the EVM which I will be overriding with only the newer board cfg yaml file. No other change is needed here. UBoot target will be "k3-r5" machine to cross compile for MCU R5F target. 

    • MAIN R5F -> Just build the FreeRTOS project with my FW app via the RTOS SDK/PDK. Use sciclient Api to request resources. Nothing more to do here. 

    Thanks,

    Prasanna 

  • 0 in reply to Prasanna Raghunathan
    TI__Guru*** 125395 points

    Hi Prasanna,

    Prasanna Raghunathan said:
    Uboot is my preferred Bootloader and I don't want to use the standalone SBL provided from the RTOS SDK.

    Thanks for clarifying. With this, you would use RTOS SDK only to build your FreeRTOS based application firmwares.

    Prasanna Raghunathan said:
    MCU R5F -> Uses Uboot SPL as SBL. Looks like I need to pull in the rm-cfg.yaml and integrate it into Uboot flow to generate the tiboot3.bin. This will address the resource management part. Now the pin mux should also be applied to Uboot va the device tree include file from sysconfig. I am already applying the DDR phy cal customizations here.

    Yeah, U-Boot code has all the needed infrastructure pieces like binman. Most of this will be part of creating/adding your own board specific dtsi/dts files, that are typically built by including the common TI SoC dtsi files.

    tiboot3.bin and sysfw.itb are your primary starting bootloader files, with tispl.bin and u-boot.img the A72 core related secondary bootloader files. 

    Prasanna Raghunathan said:
    This binary should already have a default DM implementation for the EVM which I will be overriding with only the newer board cfg yaml file. No other change is needed here. UBoot target will be "k3-r5" machine to cross compile for MCU R5F target.

    Once you have the baseline U-Boot steps figured out, the Yocto recipes can be adapted/overridden to build the same through Yocto. Obviously, this would involve some downstream recipes at your end.

    Prasanna Raghunathan said:
    MAIN R5F -> Just build the FreeRTOS project with my FW app via the RTOS SDK/PDK. Use sciclient Api to request resources. Nothing more to do here. 

    Yes, correct.

    I believe you got all your primary questions answered, to get you started. Let us know if you need any further clarifications.

    regards

    Suman