• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 204 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: Uboot + GHS Integrity Loading MCU Plus SDK CPSW Ethernet Examples on Cortex-R5F0_1 Core

Stuart Baker
Genius 10630 points
Part Number: AM6442

Tool/software:

This is a continuation of the following E2E thread:

 AM6442: MCU Plus SDK CPSW Ethernet Examples on Cortex-R5F0_1 Core 

...whereby the customer wants to run the CPSW Ethernet examples on Cortex-R5F0_1 Core, and needs to change the DMA resource ownership using the TI SCI interface to the device manager. In the other thread, customer used a modified SBL flow to update the DMA resource ownership. Now, the customer wants to switch to a U-Boot (SPL) flow to do the same. The expected boot flow would look something like this:

  1. R5 ROM
  2. SPL Loaded R5, SYSFW loaded to DMSC
  3. R5 SPL configs DDR and starts A53
  4. SPL runs on A53
  5. U-Boot runs on A53
  6. GHS Integrity runs on A53
  7. Integrity uses their equivalent of "remote proc" to load and start the R5F0_1 core

...and yes, we are aware that the "SPL" images are also technically cut down configurations of U-Boot.

Our assumption going in is that one of the Device Tree configurations (R5 SPL, A53 SPL, A53 U-Boot, or GHS Integrity) could be modified to setup the DMA resource ownership, rather than writing custom code to make the appropriate TI SCI Client calls. After reviewing the U-Boot DTS and source files, I'm not so sure if that is possible or not.

In this boot flow, where would we expect the DMA resource ownership to be setup? Do we have any similar examples that we can look at for a reference?

Thanks,

Stuart

  • 0
    TI__Expert 3480 points

    Hi Stuart,

    In the U-boot SPL flow, the resource allocation blob is packaged along with the Linux image itself. I would like to understand the requirement little clearer here. Does the customer want to update the resource configuration from linux? Or the intention is to transfer the ownership of DMA resources to R5FSS_0_1 so that it is free to use the peripheral?

    If the latter is the requirement, then you can use the following FAQ to update the Linux resource partition, and create new linux image, which will have updated resource config, without making any additional requests/changes during boot.

    Regards,
    Teja.

  • 0 in reply to Teja Rowthu
    TI__Genius 10630 points

    Teja,

    Thank you for the very fast reply. This is the goal:

    ...the intention is to transfer the ownership of DMA resources to R5FSS_0_1 so that it is free to use the peripheral...

    ...but rather on Linux, on GHS Integrity, which uses a similar boot flow to Linux. So in our typical Linux boot flow, the Linux resource partition needs to be modified. That makes sense. I would expect that GHS Integrity to have something similar, or perhaps to use our Linux resource partition method in their own kernel. I will ask the customer to check on this with GHS.

    Thanks,

    Stuart

  • 0 in reply to Stuart Baker
    TI__Expert 3480 points

    Stuart,

    Since our current Linux system uses .yaml based configuration, customer should be able to pick up the configuration from the tool and plug into their workflow, in ideal case. 

    Please keep us posted on this. Looking forward to know this about GHS integrity.

    Regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 90 points

    Hi Teja,

    I'm the customer in question here, thanks very much for your replies, I'll take some time to go over it as I also coordinate with GHS about their approach to remoteProc. Fun stuff!

    Cheers,

    Dawn

  • 0 in reply to Dawn Foran
    TI__Expert 3480 points

    Hi Dawn,

    Looking forward for the updates! Please let us know if you have any further queries, or need support on them.

    Regards,

    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 90 points

    Hi Teja,

    So I've successfully followed the FAQ you linked to, rebuilt my tiboot3 which appears to work (doesn't break anything in our existing GHS code running on A53), but while I'm waiting for GHS support on their remoteproc process, I was wondering if there is a way I can verify that the changes were properly brought into uboot?, perhaps with commands in the uboot prompt?

    Thanks!

    Dawn

  • 0 in reply to Dawn Foran
    TI__Expert 3480 points

    Hi Dawn,

    If you would like to verify if the changes were actually getting applied, you can remove the cpsw resources completely from A53 core, and that should lead to failure while opening native cpsw driver. Same applies for ICSSG as well. This confirms that the changes made are actually applied and reflected in the resource configuration. This can later be changed back to your required configuration when the remoteproc driver is ready.

    I am not aware of any methods to load R5 firmware from u-boot prompts. But I will have to check with our Linux experts for any possibility. I will update you in 2 days.

    Regards,
    Teja.

  • 0 in reply to Teja Rowthu
    TI__Expert 3480 points

    Hi Dawn,

    There is a remoteproc support available as part of U-boot. So, if the GHS integrity is also using U-boot, then you can use the u-boot based remoteproc support to temporarily test the functionality of the fix.

    Please let me know if you have any further queries.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 90 points

    Hi Teja,

    Slow going over here, been waiting for support from another of our departments which has done this before with Integrity on the A53. Currently reading up on how uboot / remoteproc works, I'll post back in the near future with findings. Thanks!

    Dawn

  • 0 in reply to Dawn Foran
    TI__Expert 3480 points

    Thank you Dawn, Looking forward to understand the results!

  • 0 in reply to Teja Rowthu
    Prodigy 90 points

    Hi Teja,

    Finally got access to the other departments repo, unfortunately I need to wait until next week to talk to someone who can put what I'm seeing in context for me. 

    One thing that stands out to me from what I'm seeing, is that the code I was pointed to is using MCU SDK bootloader.h calls, such as Bootloader_parseMultiCoreAppImage, Bootloader_isCorePresent, etc. Now, to my understanding from the Ti academy, these types of calls are used in the Ti SBL boot flow, not the u-boot SPL boot flow. Is my understanding correct here?

    Also, I also found documentation on u-boot remote proc calls, specifically "rproc" which appears to be usable from the u-boot prompt, so I attempted to use these on our u-booted EVM, and I find that they dont exist ("unknown command 'rproc'"). Is it possible our u-boot build is incorrect?, is this driver enabled in the Ti uboot by default?. The r5 defconfig files for our uboot build have the following entries set

    CONFIG_SPL_REMOTEPROC=y

    CONFIG_CMD_REMOTEPROC=y

    CONFIG_REMOTEPROC_TI_K3_ARM64=y

    and the a53 defconfig has the third one set.

    I also see aliases in the dts setting:

            remoteproc0 = &sysctrler;
            remoteproc1 = &a53_0;

    Incase it helps, the uboot 'version' command gives:

    U-Boot 2023.04-g8d7b2faf77-dirty (Aug 22 2025 - 15:41:25 -0400)

    aarch64-none-linux-gnu-gcc (Arm GNU Toolchain 11.3.Rel1) 11.3.1 20220712
    GNU ld (Arm GNU Toolchain 11.3.Rel1) 2.38.20220708

    Is there something we're missing in there?

    Thanks again for your time in this,

    Dawn

  • 0 in reply to Dawn Foran
    TI__Expert 3480 points

    Hi Dawn,

    Thank you for the details. Though I have experience with integrating R5F applications alongside Linux, I am not expert in the linux environment (yet). Please let me consult corresponding experts, and validate that the uboot based rproc is available, and usable for the current scenario.

    Please expect a response in 2 working days.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 90 points

    Hi Teja,

    So I finally had a chance to discuss with the other team. It turns out that they are using bootloader and sciclient code taken from the MCU+ SDK directly in their Integrity application running on the A53#0, while still bringing the system up with the SPL / u-boot process to get to the point of putting their monolith on the A53. Fascinating stuff. Unfortunately we haven't woken up the MMC driver yet in Integrity so I haven't been able to port and test this approach on our side. So that answers that regarding the integrity environment.

    I am still curious how come rproc doesn't appear to be part of the Ti u-boot, theoretically we should be able to leverage this feature to bring up remote cores as well. Did you get a chance to learn about that?

    Thanks!

    Dawn

  • 0 in reply to Dawn Foran
    TI__Expert 3480 points

    Hi Dawn,

    I was not able to test this myself till now being busy in other commitments. Let me bring in the experts, and verify in our setup. I will keep you posted on this. Please expect a response in 1 day.

    Regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 90 points

    Hi Teja,

    Quick update, I pulled the latest non-RC branch directly from DAS U-boot (v2025.7) and rebuilt u-boot.img from there, and now I have access to rproc. I guess it wasn't there yet in the ti version that we started from.