• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 103 subscribers
  • Views 1578 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: R5F Lockstep using u-boot

Adam Kubiak
Intellectual 920 points
Part Number: TDA4VM

Hi,

I have a few questions regarding the lockstep for R5F using u-boot.

I am using the 06_02 SDK version.

In the k3-j721e-mcu-wakeup.dtsi file the lockstep for MCU R5F is enabled, but the R5F boots without the lockstep.
I attached the screenshot from the CCS debugger with the CTRLMMR_MCUSEC_CLSTR0_CFG register settings.

According to the data from the register the CPU lockstep bahaviour is disabled and the LOCKSTEP is turned off.

How can we enable the lockstep for the MCU R5F cores using u-boot?

How can we enable the lockstep for the MAIN R5F cores using u-boot? Does enabling the lockstep in k3-j721e-main.dtsi file is enough to enable the lockstep?

  • 0
    TI__Guru**** 155580 points

    Hi Adam,

    I believe you are loading the mcu r5f firmware at the R5 SPL level. Then in that case the default efuse values are used.
    That can be either in split mode or lockstep based on the samples.

    Now if you load the firmware and boot the r5fs in u-boot or linux then the DT property takes effect and you
    can boot any of the r5fss in either lockstep-mode or split-mode based on the DT property.

    So if you want to start/load any of the r5fs in the lockstep-mode advice you to load the firmware and start them from u-boot
    instead of R5 SPL.

    Regards,
    Keerthy
     

  • 0 in reply to Keerthy J
    Intellectual 920 points

    Hi,

    We are loading the R5F firmware using the remoteproc. The firmware is stored on sd card in rootfs/lib/firmware.

    Regards,

    Adam

  • 0 in reply to Adam Kubiak
    TI__Guru**** 155580 points

    Hi Adam,

    Could you please share the entire boot log so that i can investigate what exactly is happening.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 920 points

    Hi,

    I will provide you the log as soon as I can.

    I have a question is the way we are booting the R5F cores the one that uses the configuration from the device tree?

  • 0 in reply to Adam Kubiak
    Intellectual 920 points

    Hi,

    I attached the log from u-boot.

    u-boot_log.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    U-Boot SPL 2019.01-dirty (Mar 10 2020 - 11:15:05 +0100)
    SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.1-v2019.12a (Terrific Lla')
    Trying to boot from MMC2
    Loading Environment from MMC... *** Warning - No MMC card found, using default e nvironment
    Remoteproc 2 started successfully
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.2(release):ti2019.05-rc1
    NOTICE: BL31: Built : 09:32:00, Feb 17 2020
    I/TC:
    I/TC: OP-TEE version: ti2019.05-rc1-dev (gcc version 8.3.0 (GNU Toolchain for th e A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 Mon Feb 17 09:40:16 UTC 2020 aarch64
    I/TC: Initialized
    U-Boot SPL 2019.01-dirty (Mar 10 2020 - 11:14:45 +0100)
    Detected: J7X-BASE-CPB rev E3
    Detected: J7X-VSC8514-ETH rev E2
    Trying to boot from MMC2
    U-Boot 2019.01-dirty (Mar 10 2020 - 11:14:45 +0100)
    SoC: J721E PG 1.0
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E6
    DRAM: 4 GiB
    Flash: 0 Bytes
    MMC: sdhci@4f80000: 0, sdhci@4fb0000: 1
    Loading Environment from MMC... *** Warning - bad CRC, using default environment
    In: serial@2800000
    Out: serial@2800000
    Err: serial@2800000
    Detected: J7X-BASE-CPB rev E3
    Detected: J7X-VSC8514-ETH rev E2
    Net:
    Warning: ethernet@046000000 using MAC address from ROM
    eth0: ethernet@046000000
    Hit any key to stop autoboot: 0
    => setenv dorprocboot = 1
    => boot
    switch to partitions #0, OK
    mmc1 is current device
    SD/MMC found on device 1
    ** Unable to read file boot.scr **
    0 bytes read in 0 ms
    Loaded env from uEnv.txt
    Importing environment from mmc1 ...
    2219644 bytes read in 54 ms (39.2 MiB/s)
    Load Remote Processor 3 with data@addr=0x80080000 2219644 bytes: Success!
    86984 bytes read in 9 ms (9.2 MiB/s)
    Load Remote Processor 4 with data@addr=0x80080000 86984 bytes: Success!
    ** File not found /lib/firmware/j7-c66_0-fw **
    ** File not found /lib/firmware/j7-c66_1-fw **
    ** File not found /lib/firmware/j7-c71_0-fw **
    13338632 bytes read in 284 ms (44.8 MiB/s)
    99354 bytes read in 3 ms (31.6 MiB/s)
    ## Flattened Device Tree blob at 82000000
    Booting using the fdt blob at 0x82000000
    Loading Device Tree to 00000000fdda3000, end 00000000fdebefff ... OK
    Starting kernel ...
    [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd080]
    [ 0.000000] Linux version 4.19.94-g5a23bc00e0 (oe-user@oe-host) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 SMP PREEMPT Mon Feb 17 09:01:06 UTC 2020
    [ 0.000000] Machine model: Texas Instruments K3 J721E SoC
    [ 0.000000] earlycon: ns16550a0 at MMIO32 0x0000000002800000 (options '')
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I will also repeat my question.

    Is the way we are booting the R5F cores the one that uses the configuration from the device tree?

  • 0 in reply to Adam Kubiak
    TI__Guru**** 155580 points

    Hi Adam,

    R5 SPL is doing 2 things:

    1) Loads main_r5fss0_core0 firmware and starts it in split mode as the DT has lockstep-mode = <0> in arch/arm/dts/k3-j721e-main.dtsi.
    Hence you see the message in your boot log:
    Remoteproc 2 started successfully.

    Remoteproc 2 for r5 is the main_r5fss0_core0  if you see the arch/arm/dts/k3-j721e-r5-common-proc-board.dts:

    aliases {
    remoteproc0 = &sysctrler;
    remoteproc1 = &a72_0;
    remoteproc2 = &main_r5fss0_core0;
    remoteproc3 = &main_r5fss0_core1;
    };

    So main_r5fss0 is booted in split mode as per the DT configuration.

    Please check:
    http://www.ti.com/lit/pdf/spruil1

    CTRLMMR_SEC_CLSTR0_CFG Register Address: 0x45A40040

    bit 3: lockstep_en if its set then lockstep mode is supported on the device.


    You could try to change arch/arm/dts/k3-j721e-main.dtsi:

    main_r5fss0: r5fss@5c00000 {
    compatible = "ti,j721e-r5fss";
    lockstep-mode = <0>;

    to

    main_r5fss0: r5fss@5c00000 {
    compatible = "ti,j721e-r5fss";
    lockstep-mode = <1>;

    And try to get main_r5fss in lockstep-mode subjected to LOCKSTEP_EN bit set.

    2) Once SPL is done with its tasks it is jumping to a firmware:

    jump_to_image_no_args function in arch/arm/mach-k3/common.c.

    This does not take any DT property as the mcu r5 itself is executing the SPL and hence for
    this we do not read the DT property. So i believe by default on your samples mcu_r5f is in split mode.

    Look at the description of Table 5-660. CTRLMMR_MCUSEC_CLSTR0_CFG Register Field Descriptions:

    in: www.ti.com/.../spruil1

    Bit 3: LOCKSTEP_EN is 0 on your sample which implies: 

    Lockstep enable. Indicates if R5 lockstep operation is supported on
    the device

    Your register reads 0x0 which means lock step not supported.

    So MCU_r5ss in lockstep mode is not supported on your sample.

    Hope this clarifies the behavior on your board.

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Intellectual 920 points

    Hi Keerthy,

    Thank you for that analysis.

    I checked the CTRLMMR_SEC_CLSTR0_CFG Register and the lockstep for the MAIN R5F is also not enabled.

    I'm attaching the screenshot:

    Does this mean that even if i enable the lockstep for MAIN R5F in  arch/arm/dts/k3-j721e-main.dtsi it won't work?

    Or if i enable the lockstep in the device tree the MAIN R5F should boot in a lockstep mode?

    Kind regards,

    Adam

  • 0 in reply to Adam Kubiak
    TI__Guru**** 155580 points

    Hi Adam,

    As replied earlier only of the LOCKSTEP_EN is enabled on your device it can be supported.

    lockstep_en = !!(stat & PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED);
    if (!lockstep_en && cluster->mode) {
    dev_err(cluster->dev, "lockstep mode not permitted, force configuring for split-mode\n");
    cluster->mode = 0;
    }

    The above code in Linux clearly checks that and supports only split-mode if lockstep_en is not set.

    So for your case this will not be supported.

    Hope you can resolve the issue with information provided.

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Intellectual 920 points

    Hi Keerthy,

    Thanks for the help.

    I have one last question.

    Is there any way I can enable the lockstep or is it disabled on a hardware level? And if yes how can i do that?

    We are using the evaluation board but we also have our custom hardware with TDA4.

  • 0 in reply to Adam Kubiak
    TI__Guru**** 155580 points

    Hi Adam,

    I consulted the expert in R5F domain. The lockstep-mode_en bit tells that it is not supported on your device.
    Lockstep mode cannot be supported on your device i confirm. Please resolve the issue.

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    TI__Mastermind 33070 points

    Hi Adam,

    Just a point on reading CTRLMMR_SEC_CLSTR0_CFG registers.

    Try reading the registers from M3, instead of R5.
    The access to these registers from other cores may have been blocked in latest release.

    Regards,
    Vishal