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.

66AK2H14: How to prevent Linux kernel from putting the DSP cores in reset on boot?

Part Number: 66AK2H14

Hi,

We are using the 66AK2h14 on our custom board with kernel 4.19.61.

There is the remoteproc driver for giving tasks to the DSP cores. It is said that that driver needs to put the DSP cores into reset before it can load code to them.

In this case, however, the DSP cores are supposed not to take any orders from the ARM cores, and therefor, the remoteproc driver is not included in the kernel.

It seems, however, that for some reason, the DSP cores are still put into reset at some point when the kernel boots.

Is this a known feature? If it is, is there any known way to prevent this? Or, are there any directions or hints available for preventing of the reset?

  • Hello,

    I believe the DSP cores are powered down by u-boot during boot. Please see if the guidance in section 3.7.5.8 of the following guide helps.

    http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_IPC.html#loading-dsp-images-from-ccs-without-using-mpm

    Regards,
    Sahin

  • Hi,

    As far as I know, our version of U-Boot has already been patched to leave the DSP cores running. After doing that, we noticed that kernel is still putting them into reset.

  • Hi,

    I try to understand what issues you encounter with DSP in reset. Is it download not working? 

    You mentioned your kernel version is 4.19.61. It doesn't sound like the Linux SDK kernel release. The release note shows kernel version is 4.19.38. Do you clone the kernel from git.ti.com and did you switch to processor-sdk-linux branch as indicated in the release note?

    The remoteproc is built in the kernel for Keystone-2 devices and only handles power on/off. The DSP will be out of reset if MPM downloads code to it. I don't see why it is an issue and need to keep DSP out of rest all the time. 

    Rex

  • Hi,

    We haven't heard back from you. Is your question answered and issue resolved? As mentioned in previous post, the DSP in reset doesn't prevent the binary be downloaded and run on DSP.

    Rex

  • Hi,

    Thanks for your answers and sorry for taking so long to say anything. I have been and I still am finding out stuff that I need for more complete an answer.

    In the meanwhile, I can say that

    - We are using a kernel that is more recent than the TI kernel due to some other driver issues.

    - In this case, offloading of tasks to the DSP cores will not be handled using the remoteproc driver but some other means.

    - The DSP cores are needed to keep doing their own tasks regardless of what the ARM cores do. Consequently, the ARM cores can't be allowed to reset them.

  • Hi,

    Please take a look at the section http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/How_to_Guides.html#taking-the-c66x-out-of-reset-with-linux-running-on-the-arm-a15 and the K2HK gel file in CCS, C:\ti\ccsv8\ccs_base\emulation\boards\xtcievmk2x\gel\xtcievmk2x.gel.

    You may want to try to set the PDCTLx and MDCTLx for the DSPs as what are done in K2HK_out_of_reset() 

    Rex

  • Hi again,

    Here is some clarification to what I am after.

    In this solution, there will be a custom SoC bootloader that starts both ARM and DSP sides. After that, the ARM side runs first U-Boot and then Linux, and the DSP side runs its own code. Neither U-Boot nor Linux running on the ARM side must not reset the DSP cores.

    Currently, however, Linux kernel does reset the DSP cores at some point during its boot-up unless the remoteproc driver is included in the kernel. If it is included, the reset won't happen, but as a "side effect", kernel starts freezing randomly during the boot-up.

    What is needed is to prevent the kernel from resetting the DSP cores, and I see two alternative ways to do that. The first one is to somehow patch the kernel or perhaps modify the device tree configuration so that the reset won't happen. The second one is to find out why remoteproc freezes the kernel during the boot-up and fix that. Any tips related to either of these two ways would be welcome.

  • Hi,

    remoteproc freezes the kernel during the boot-up

    We have not seen this issue and I can't reproduce it. Our PLSDK release has remoteproc included and passed the system test for release. Could you elaborate how to reproduce it and any changes you made to the kernel if any?

    I am also confused on your statement

    Linux kernel does reset the DSP cores at some point during its boot-up unless the remoteproc driver is included in the kernel. If it is included, the reset won't happen,

    I looked at the code, and it is actually opposite to your statement.The PSC control is in dts file and is set to deassert reset. However, in the remoteproc code, keystone_rproc_probe() "ensure the DSP is in reset before loading firmware", it checks the reset status by calling reset_control_status(). If device is not in reset, it calls keystone_rproc_dsp_reset() to set DSP in resest mode. I don't see other places where the DSP is put in reset than calling from MPM. Triggering from MPM doesn't apply to your case because you are not using mpmcl at all.

    You may want to try removing keystone_rproc_dsp_reset() call in keystone_rproc_probe(), but your statement of having issue with remoteproc included makes me think this may not even apply to you.

    Rex

  • Hi,

    I don't know how to reproduce the kernel freeze issue. All I know is that it happens with this software.

    I removed the call to keystone_rproc_dsp_reset() as you suggested and then run a test repeatedly. There is a led in the hardware that indicates by blinking that the DSP side is doing it's job uninterrupted. In 20 boots, I got 5 freezes and 11 cases when the led stopped blinking.

    The kernel boot log is the same in every case. Here is what I get for DSP core 0:

    [ 3.126651] keystone-rproc 10800000.dsp: Runtime PM disabled, clock forced on.
    [ 3.135329] keystone-rproc 10800000.dsp: device does not have specific CMA pool
    [ 3.142679] keystone-rproc 10800000.dsp: device is not in reset
    [ 3.148663] remoteproc remoteproc0: 10800000.dsp is available
    [ 3.154542] remoteproc remoteproc0: Direct firmware load for keystone-dsp0-fw failed with error -2
    [ 3.163554] remoteproc remoteproc0: powering up 10800000.dsp
    [ 3.176531] remoteproc remoteproc0: Direct firmware load for keystone-dsp0-fw failed with error -2
    [ 3.192841] remoteproc remoteproc0: request_firmware failed: -2

  • Hi,

    The logs to me don't seem to be power issue, but not having CMA pool. It seems to me that it is the cause of load failure. How is the DSP image downloaded? Do you have a startup script to download or you write your own code to get it downloaded?

    Rex

  • Hi,

    Could it be that not having CMA pool would be causing the freezes? There is something in the device tree that I think is the configuration for them, but it hasn't been verified whether that configuration is correct.

    The failure to load firmware per se is not an issue to me. There is no need for that to succeed, and it actually would be preferable to be able to prevent any attempts to do that. The DSP side should be running their own code started by the SoC boot loader.

  • Hi,

    I found out something. I booted a kernel without remoteproc using a dtb that has all references to the DSP cores removed. Once U-Boot had downloaded the files needed for booting the kernel (over TFTP), I unplugged the network cable. The boot stopped right before configuring the network and mounting rootfs over NFS. DSP cores had not been reset at that point. When I plugged the network cable again, DSP cores got reset. That behaviour is repeatable.

    To me this looks as if either something in configuring the network or mounting the rootfs is causing the DSP reset or something else is causing it but is for some reason being delayed until those operations.

    Also, I discovered a feature called Early Boot and Late Attach that is available for some other hardware (http://processors.wiki.ti.com/index.php/Early_Boot_and_Late_Attach_in_Linux).

    That sounds pretty much similar to what I am aiming at.

  • Hi,

    K2H does not support Early Boot Late Attach. There are more changes required in Kernel than keeping DSP out of reset.

    Rex