• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 62 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.

TMDS64EVM: Issue starting R5FSS0_0 from U-Boot SPL on AM64x

Philippe Schenker
Prodigy 30 points
Part Number: TMDS64EVM

Tool/software:

Hello

I'm trying to start three R5 cores as early as possible using U-Boot SPL, because our system has strict timing requirements and the R5 subsystem needs to be running quickly.
I've added firmware loading and processor startup code to spl_board_init() in U-Boot that is running on R5. This setup works for loading/starting R5FSS1_0 and R5FSS1_1. Both cores start up correctly and run the firmware as expected.
However, when I try to start R5FSS0_1, nothing happens. All function calls (e.g. load, start) return successfully. At the end, I call ti_sci_proc_get_status(), which returns the following:

proc_id = 2, boot_vector = 0xx, cfg_flags = 0x1803, ctrl_flags = 0x0, sts = 0x0

This looks like everything worked and the core should be running.But it clearly isn't doing anything. When I load the same firmware on R5FSS1_0, it executes fine, so I don't think it's a firmware issue.

I'm using mainline U-Boot v2025.04, and in the binman DTSI, I’ve set: core-opts = <2>;

Here is the rough sequence I'm using in SPL to bring up the R5 cores:

mmc_init(...);
blk_dread(...);

rproc_dev_init(rproc_id);
rproc_stop(rproc_id);
rproc_reset(rproc_id);

rproc_load(rproc_id);
rproc_start(rproc_id);
udelay(1000);
ti_sci_proc_get_status(...);

Questions / Things I'm unsure about:

  • Is there anything special about R5FSS0_0 that might prevent it from starting in SPL?

  • Are additional steps required for R5FSS0_0 specifically?

  • Is core-opts = <2>; sufficient in this context?

Any ideas or hints would be greatly appreciated.

Best regards,
Philippe

  • 0
    TI__Guru** 101800 points

    Hello Philippe,

    To set expectations, you are writing custom code that TI does not support. I will be limited in the assistance that I can offer.

    Supported boot methods

    The TI-supported methods for initializing non-Linux cores are:
    during SBL (SBL boot only)
    during u-boot with rproc
    from Linux with remoteproc

    for more information about all 3 methods, please refer to the AM64x academy's Multicore module:
    Booting & disabling processor cores > Methods to initialize remote cores
    https://dev.ti.com/tirex/explore/node?node=A__Ab5AogqjWTRWB1yUfHHjTw__AM64-ACADEMY__WI1KRXP__LATEST

    Let's talk about your usecase 

    Keep in mind that the R5F part of SPL is running on R5F0_0. So if you try to load new firmware into the R5F0_0 while it is still executing the R5F SPL code, then I would expect it to fail. If I was trying to load the R5F0_0 runtime code from R5F SPL, I would do loading firmware into R5F0_0 as the very last thing that the R5F SPL does.

    The SBL examples may be a helpful reference. Here's the R5F0_0 SBL code that runs when booting Linux and storing the filesystem on EMMC:
    https://github.com/TexasInstruments/mcupsdk-core/blob/next/examples/drivers/boot/sbl_emmc_linux/am64x-evm/r5fss0-0_nortos/main.c

    Where you'll see things that the R5F0_0 is doing to itself with the ID "CSL_CORE_ID_R5FSS0_0" and to R5F0_1 with the ID "CSL_CORE_ID_R5FSS0_1"

    Regards,

    Nick