• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 368 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.

Original question:

[FAQ] TDA4VM: Different ways to load an RTOS or Baremetal application along with Linux

TDA4VM: Restrictions when loading custom MCU1_0 app via R5 SPL and/or U-Boot

felix_123
Expert 1251 points
Part Number: TDA4VM

Hi TI,

I want to load a custom FreeRTOS application on MCU1_0 alongside with Linux. I am using PSDK v08.02 for both Linux and RTOS and I am using the standard TI dev board. I was following this thread (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/915474/faq-tda4vm-different-ways-to-load-an-rtos-or-baremetal-application-along-with-linux) to test out loading via R5 SPL and loading via U-Boot.

Since loading via R5 SPL has the following restrictions:

  • TCMA is disabled
  • 1 MB SRAM loacted at MCU Interconnect (starting at address 0x41C0 0000) can not be used

I wanted to switch to loading via U-Boot. My assumption is, that at least 1 MB SRAM (0x41C0 0000) is not reserved anymore (https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/psdk_rtos/docs/user_guide/developer_notes_mcu1_0_sysfw.html , section 8.3.2.3). 

Q1: Is this assumption correct? What about TCMA? Can it be used for custom app?

The before mentioned FAQ, mentions that "Skipping MCU1_0 load from R5F SPL and then loading from u-boot is not possible". This is related to the architectural change from SDK v07.01, where MCU1_0 is now a part of the boot process.

Q2: I am still not sure how to interpret this sentence. Is it generally not possible to load a custom application to MCU1_0 via U-Boot from SDK v07.01 and onwards?

Assuming, that it is possible to load MCU1_0 app via U-Boot, "some" MCU1_0 app still needs to be loaded via R5 SPL, to meet the boot requirements and being able to boot to U-Boot. I placed my custom app in an NFS directory at /lib/firmware/j7-mcu-r5f0_0-fw and booted to U-Boot. To load the app, I did all the changes provided by vision apps user guide to load apps via NFS boot (https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_02_00_05/exports/docs/vision_apps/docs/user_guide/RUN_INSTRUCTIONS.html#run_steps_linux_nfs). I additionally modified rproc_fw_binaries to

rproc_fw_binaries=0 /lib/firmware/j7-mcu-r5f0_0-fw

so that only MCU1_0 gets loaded and started. The image I want to load is identical to the one loaded by R5 SPL. This is the log I get from U-Boot doing the steps I mentioned before:

link up on port 1, speed 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.16.1.158 (4 ms)
link up on port 1, speed 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.16.1.158 (3 ms)
link up on port 1, speed 1000, full duplex
Using ethernet@46000000 device
File transfer via NFS from server 172.16.1.147; our IP address is 172.16.1.158
Filename '/home/felix/ti-processor-sdk-linux-j7-evm-08_00_00_08/targetNFS-test//lib/firmware/j7-mcu-r5f0_0-fw'.
Load address: 0x82000000
Loading: ###########################################
done
Bytes transferred = 217356 (3510c hex)
Invalid op: Trying to load/start on already running core 1

So it seems that MCU1_1 is already running. This can be explained, since MCU1_0 and MCU1_1 are started in lockstep mode. I am trying to avoid this error by manually stopping both MCU1_0 and MCU1_1 via following U-Boot commands:

=> rproc init
=> rproc stop 0
=> rproc stop 1
Invalid op: Trying to stop secondary core in lockstep mode
Operation Failed with error (-22)
=>

After booting the board, I get the following output:

=> boot
switch to partitions #0, OK
mmc1 is current device
SD/MMC found on device 1
0 bytes read in 0 ms
Loaded env from uEnv.txt
Importing environment from mmc1 ...
link up on port 1, speed 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.16.1.158 (4 ms)
link up on port 1, speed 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.16.1.158 (3 ms)
        Remote Processors are already initialized
link up on port 1, speed 1000, full duplex
Using ethernet@46000000 device
File transfer via NFS from server 172.16.1.147; our IP address is 172.16.1.158
Filename '/home/felix/ti-processor-sdk-linux-j7-evm-08_00_00_08/targetNFS-test//lib/firmware/j7-mcu-r5f0_0-fw'.
Load address: 0x82000000
Loading: ###########################################
done
Bytes transferred = 217356 (3510c hex)
ti_sci_get_response: Message receive failed. ret = -110
Mbox send fail -110
ti-sci processor set_config failed: -110
ti_sci_get_response: Message receive failed. ret = -110
Mbox send fail -110
ti-sci processor release failed: -110
ti_sci_get_response: Message receive failed. ret = -110
Mbox send fail -110
ti-sci processor release failed: -110
Load Remote Processor 0 with data@addr=0x82000000 217356 bytes: Failed!

So somehow, the Sciserver is not correctly started.

Q3: Since the app I wanted to load via U-Boot is the same, which I previously loaded via R5 SPL, I do not understand why I get this error. Can you please explain this bevaviour?

Q4: Is starting MCU1_0 and MCU1_1 in split mode recommended? I found the following thread (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1003532/tda4vm-tda4vm---enable-mcu_r5f-lockstep-or-split-using-u-boot)  but the solution provided seems not very "official"?

Thanks for your help and best regards,

Felix

  • 0
    TI__Guru* 77274 points

    Hi Felix

    felix_123 said:
    What about TCMA?

    Loading MCU1_0 from u-boot will not be supported as the MCU1_0 is now running the DM (Device Manager) since SDK7.1 (see this) and hence the MCU1_0 firmware is required to boot other cores.

    With MCU1_0 not up, you will be able to get to u-boot itself.

    felix_123 said:

    Q1: Is this assumption correct? What about TCMA? Can it be used for custom app?

    The before mentioned FAQ, mentions that "Skipping MCU1_0 load from R5F SPL and then loading from u-boot is not possible". This is related to the architectural change from SDK v07.01, where MCU1_0 is now a part of the boot process.

    This is correct. Any questions / clarifications needed here?

    felix_123 said:

    Q2: I am still not sure how to interpret this sentence. Is it generally not possible to load a custom application to MCU1_0 via U-Boot from SDK v07.01 and onwards?

    Assuming, that it is possible to load MCU1_0 app via U-Boot, "some" MCU1_0 app still needs to be loaded via R5 SPL, to meet the boot requirements and being able to boot to U-Boot.

    I understand what you are trying to do, let me try to explain what I feel the issue would be.

    You need the Sciserver or DM to be running when you are trying to boot any core. (as this requires RM & PM services from the DM)

    When you do "rproc stop 0" at this point you kill the DM and hence will no longer have the ability to boot other cores.

    felix_123 said:
    Q3: Since the app I wanted to load via U-Boot is the same, which I previously loaded via R5 SPL, I do not understand why I get this error. Can you please explain this bevaviour?

    Answered above.

    felix_123 said:
    Q4: Is starting MCU1_0 and MCU1_1 in split mode recommended? I found the following thread (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1003532/tda4vm-tda4vm---enable-mcu_r5f-lockstep-or-split-using-u-boot)  but the solution provided seems not very "official"?

    This is correct, this is not officially tested in the SDK.

    felix_123 said:
    What about TCMA?

    If all you need is to use TCM-A then you can add the piece of code in the R5 SPL to do this. But again, this is not officially supported.

        asm(" MRC p15, #0, r0, c9, c1, #1 ");
    asm(" BFC r0, #12, #20 ");
    asm(" ORR r0, r0, #0x1 ");
    asm(" MCR p15, #0, r0, c9, c1, #1 ");

    Regards

    Karan

  • 0 in reply to Karan Saxena
    Expert 1251 points

    Hi Karan, 

    thanks for your detailed answer.

    Karan Saxena said:
    I understand what you are trying to do, let me try to explain what I feel the issue would be.

    That was just a naive approach to avoid the error message. Summarizing: A custom application for MCU1_0 can only be loaded by R5 SPL (with SDK v07.01 and onwards). Loading it via U-Boot or via Linux remoteproc is not possible, because I would have to stop and restart Sciserver, DM, PM, RM, ... which is not possible. Is this correct?

    I am still a little bit confused about activating TCMA via your proposed assembler code, since the FAQ, which I mentioned in my previous post also states that  I must "Not overwrite the MPU entries used by the R5 SPL". Is TCMA already correctly set up in the applied MPU Config of R5 SPL or do I have to make changes there as well?

    Thanks again for your help and best regards

    Felix

  • +1 in reply to felix_123
    TI__Guru* 77274 points

    Hi Felix

    felix_123 said:
    Summarizing: A custom application for MCU1_0 can only be loaded by R5 SPL (with SDK v07.01 and onwards). Loading it via U-Boot or via Linux remoteproc is not possible, because I would have to stop and restart Sciserver, DM, PM, RM, ... which is not possible. Is this correct?

    I would put it in a slightly different way.

    The MCU1_0 needs to provide the DM (Device Manager) functionality at all times in the TDA4 system. When MCU1_0 is running R5 SPL then this is provided by R5 SPL and then once R5 SPL jumps to MCU1_0 custom application, then it is the Sciserver running on the custom app which provides that functionality.

    In case you do not load MCU1_0 custom application from R5 SPL then there will be a time duration in the system when there will be nothing running on the MCU1_0. This duration will be from the R5 SPL end (where it loads the A72 SPL) to the u-boot loading the MCU1_0 custom application.

    This is the reason why loading of MCU1_0 app in not supported from u-boot. Even if we modify the R5 SPL to provide DM functionality till u-boot loads the custom app, then too it may not be possible because even in that case there will be a point where we have to stop R5 SPL and then reload MCU1_0 SciServer and this loading without the DM will not be possible.

    felix_123 said:
    I am still a little bit confused about activating TCMA via your proposed assembler code, since the FAQ, which I mentioned in my previous post also states that  I must "Not overwrite the MPU entries used by the R5 SPL". Is TCMA already correctly set up in the applied MPU Config of R5 SPL or do I have to make changes there as well?

    We should not overwrite the MPU entries used by R5 SPL because the assumption is that the MCU R5 has come up with the same memories enabled in the custom app as the R5 SPL. In this case you should be able to re-configure the mpu. But I've not tried this so in case you see issues, please let me know.

    Regards

    Karan

  • 0 in reply to Karan Saxena
    Expert 2601 points

    Hi Karan,

    I am a colleague of Felix.

    Karan Saxena said:
    This is the reason why loading of MCU1_0 app in not supported from u-boot. Even if we modify the R5 SPL to provide DM functionality till u-boot loads the custom app, then too it may not be possible because even in that case there will be a point where we have to stop R5 SPL and then reload MCU1_0 SciServer and this loading without the DM will not be possible.

    Thank you very much - Now I get the bigger picture here. Thats the reason why the R5 SPL is doing a "switch over to custom firmware" without any reset. U-Boot and Linux are using the remoteproc driver/module which requires the Sciserver running, and are not capable of doing the "switch over" like R5 SPL.

    Karan Saxena said:
    In this case you should be able to re-configure the mpu. But I've not tried this so in case you see issues, please let me know.

    We assumend it is not possible / safe to do because of the requirements of an cooperative application:

    1. Conform to the mode that the core has come up
    2. Stay away from the memory that the R5 SPL is running from
    3. Not overwrite the MPU entries used by the R5 SPL

    About the 1: We would like to run MCU_R5SS in split mode. For this we got a patch of R5 SPL which seems to work.

    About the 2: We would like to use as much fast memory for the MCU_R5SS as possible. This includes the ATCM of R5 (which are disabled for R5 SPL), and MCU_MSRAM_1MB0_RAM which the first half of it is reserved for R5 SPL.

    About the 3: To use the ATCM, we would need to change the MPU configuration when/after switching to our custom firmware. Do you mean this should be able to do during/after the firmware switch or for the R5 SPL beforehand?

    Best regards,
    Thomas