• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 983 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.

AM6442: R5F early boot (before A53 uboot) how to

MH
Intellectual 290 points
Part Number: AM6442


Hello,

For our applications we need to get one of the R5F up and running as early as possible (a different core from the one running the R5F SPL), we identified that booting this other core during R5F SPL and even waiting for SYSFW to be started by the DMSC is a viable option timing wise.

Since we couldn't find any example of how to do this, could you please point us in the right direction: 

1- is there a mechanism already in place to do that (is spl_load_image() the right approach?)?,

2- in what format the R5F image we want to boot should be (how to build the R5F image to work in this load config)?

3- do we add the image to tispl.bin (by adding another blob entry in xxxbinman.dtsi)? or can we add it to tiboot3.bin?

4- where should we call the loader from (is board_init_f() the right choice or later in board_init_r()?)?

5- how to make sure the kernel does not shut down or restarts without completely disabling remoteproc (this R5F will need to interact with LInux when it is up and running)?

Thank you for your help.

  • 0
    TI__Guru 70900 points

    Hi Mehdi,
    This is not standard boot flow, and will need to discuss internally on options, and get back to you.
    Best,
    -Hong

  • 0 in reply to Hong Guan64
    Intellectual 290 points

    Hi Hong,

    Understood. FYI, this is what I had in mind:

    1- tispl.bin will have an additional blob for core R5F1_1 (let's say r5f1_1.bin)

    2- R5F0_0 running the R5 SPL  loads tispl.bin, and moves r5f1_1.bin blob in the MSRAM zone for R5F1_1 (say at 0x70180000 corresponding to its linker cmd)

    3- R5F0_0 requests that SYSFW starts R5F1_1 (with setting to start from 0x70180000).

    4- R5F1_1 requests peripheral access to SYSFW.

    Regards,

    Mehdi

  • 0 in reply to MH
    Intellectual 290 points

    Hi Hong,

    Here are some additional thoughts, we could use k3-r5-rproc uboot driver and load FW from file system:

    1- add these to R5 defconfig: CONFIG_REMOTEPROC_TI_K3_R5F, CONFIG_FS_LOADER & CONFIG_SPL_FS_LOADER

    2- add this to r5 dts:

       in aliases add: remoteproc2 = &main_r5fss1_core1;

       and:

    main_r5fss1: r5fss@78400000 {
    compatible = "ti,am654-r5fss";
    ti,cluster-mode = <0>;
    #address-cells = <1>;
    #size-cells = <1>;
    ranges = <0x78400000 0x00 0x78400000 0x10000>,
    <0x78500000 0x00 0x78500000 0x10000>,
    <0x78600000 0x00 0x78600000 0x08000>,
    <0x78700000 0x00 0x78700000 0x08000>;
    power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;

    main_r5fss1_core1: r5f@78600000 {
    compatible = "ti,am654-r5f";
    reg = <0x78600000 0x00008000>,
    <0x78700000 0x00008000>;
    reg-names = "atcm", "btcm";
    ti,sci = <&dmsc>;
    ti,sci-dev-id = <124>;
    ti,sci-proc-ids = <0x07 0xff>;
    resets = <&k3_reset 124 1>;
    firmware-name = "am64-main-r5f1_1-fw";
    ti,atcm-enable = <1>;
    ti,btcm-enable = <1>;
    ti,loczrama = <1>;
    };
    };

    3- in arch/arm/mach-k3/common.c function jump_to_image_no_args add the following right before shutting down r5f0_0 (but we could explore adding these in the custom board file instead: evm.c in function spl_board_init()):

    size = 0;
    loadaddr = 0x70180000;

    printf("%s: loading R5F1_1 FW from FS\n", __func__);
    size = load_firmware("am64-main-r5f1_1-fw", "addr_main-r5f1_1load", &loadaddr);
    if (size)
    {
    ret = uclass_get_device_by_seq(UCLASS_REMOTEPROC, 2, &dev);
    if (ret) {
    printf("Unknown remote processor id '%d' requested(%d)\n", 2, ret);
    } else {
    core = dev_get_priv(dev);
    ret = ti_sci_proc_set_config(&core->tsp, loadaddr, 0, 0);
    ret = rproc_start(2);
    printf("%s: R5F1_1 starting on rproc (%d)\n", __func__, ret);
    if (ret)
    printf("%s: R5F1_1 failed to start on rproc (%d)\n", __func__, ret);
    }
    } else {
    printf("%s: R5F1_1 failed to load firmware from FS\n", __func__);
    }

    4- additional mods in load_firmware() as it only support loading from MMC2.

    Please let me know if the above seems correct or if you have other suggestions.

    Thank you.

  • 0 in reply to MH
    TI__Guru** 103500 points

    Hello Mehdi,

    The Uboot RemoteProc driver is not an option for AM64x at this point in time. Please take a look at the MCU+ SDK SBL solutions.

    Uboot RemoteProc driver

    AM64x does NOT have uboot support for the remoteproc driver to load remote cores at this point in time (no uboot documentation at https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_02_00_17/exports/docs/linux/Foundational_Components/U-Boot/Users-Guide.html ). For future readers, AM65x does has uboot support for the remoteproc driver to load remote cores (as documented at https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/08_02_00_02/exports/docs/linux/Foundational_Components/U-Boot/UG-RemoteProc.html ).

    SBL boot 

    Please take a look at https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_31/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_SBL.html . Specifically, the OSPI Linux and EMMC Linux sections.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 290 points

    Hello Nick,

    Yes, in the solution I was questioning I used a direct firmware load from the filesystem of boot media and used ti_sci_proc_set_config to set the boot vector, only rproc_start was used to start the core.

    Thank you for pointing out the SBL route, I was not aware that SBL could be compatible with Linux. We need to modify these solutions for SD card booting for testing: I suppose we need to change the boot mode to RAW instead of FS, should we use the same addresses for the different blobs as the ones used for eMMC?

    Lastly, how to prevent linux from stopping/resetting the R5 core that was initiated at boot through the remoteproc kernel probing (we can't remove it from the device tree and can't disable rproc since we need to communicate between this R5 and linux)?

    Regards,

    Mehdi