TMDS64EVM: PRU gets no GPIO Input when run via Remoteproc

Part Number: TMDS64EVM
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hello,
I have been trying to send High Speed Extension Input data from the PRU to Linux Userspace.

Remoteproc and RPMSG work fine for me, and I can send Strings from the PRU to the assigned rpmsg file on linux.

Now, I wanted to get input from the R31, and send it over using rpmsg.
I noticed that when I boot the EVM board with Yocto Linux and connect the debugger by starting Target Configuation and connect to the PRU, after loading the firmware and starting it, that the R31 register doesn't change at all with connected input signals.



I do have a project, which starts the "empty_am64x-evm_r5fss0-0_freertos_ti-arm-clang" example, with every GPIO PRU configured to Input in the Sysconfig.
After I start that programm on R5_0_0 core, I load another Example project for the PRU, which basically does nothing but set "CT_CFG.gpcfg0_reg = 0;"
By pasing and resuming the PRU project I canread what is in the R31 Register. Now I get the expected results.



When running the PRU firmware with Remoteproc on Linux, I run the "PRU_RPMsg_Echo_Interrupt0" Example from the PRU software support package, with an added like: "CT_CFG.gpcfg0_reg = 0;"
I run this firmware by saving it on the Board(in /usr/lib/firmware) and saving the name of the firmware file in the right Pru Remoteproc(for example "echo 'firmwarename.out' > sys/class/remoteproc/remoteproc11/firmware") and then starting it, and reading the then created rpmsg_pru file with the cat command.
Then I connect to the PRU0_0 core with CCS and pause/resume it to read the Registers, but this time it stays at 0x40000000.

Am I missing something or did I fail to set a flag perhaps?
Thank you very much in advance for any help!

  • Hello,

    It sounds like you want to read in a PRU GPI signal. For that to work, we need to make sure that your pinmux is set properly.

    When Linux is initializing the PRU core, how are you setting the pinmux for the PRU signals?

    I discuss one way to set pinmuxing for the PRU from Linux in this other thread:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1442234/processor-sdk-am62x-am62x-pruss-core

    Regards,

    Nick

  • Hello Nick,
    I have tried the solutions you mentioned in the other forum posts. I went about it like this:
    I started by looking at which Pinmux settings I need to add by going to the Sysconfig and adding P_RU_ICSSG0_PRU for the Pru0_0 I want to use in this case:

    Then I went to the SDK and went to ti-processor-sdk-linux-am64xx-evm-10.00.07.04-Linux\board-support\ti-linux-kernel-6.6.32+git-ti\arch\arm64\boot\dts\ti and opened  k3-am642-evm.dts with an editor.

    I deletet rgmii1_pins_default and rgmii2_pins_default: 
    as well as &cpsw3g  :
    as they used some Prg0_Pru0 pins I needed as input.

    After that I added all the Pins I needed into the file:

    once done I translated the file using WSL ubuntu 22.04.05LTS: 

    The dtb file I then moved using scp into the Board by replacing the already existing k3-am642-evm.dtb file in /boot/dtb/ti with the newly translated file.
    I then rebootet the board. And tried to read intput again, just to be stuck at the same "0x40000000" in Register R31 when reading it through CCS whit the firmware is running.

    I have a feeling that because I only added what Sysconfig showed that it wasn't acctually used.
    I saw in the example with the Uart you mentioned to add the Pinmux setting to the related uart declaration here.
    But I didn't see anywhere with the PRU where I could have inputed the settings I needed for the PRU0_0.

    Is there anything I missed?
    Thank you in advance for your help!


  • Hello,

    Is your pinmux setting "mypru...pins_default" actually referred to by any of the devicetree nodes?

    The Linux kernel only applies pinmux settings if they are linked from a devicetree node that gets probed, so it is not enough to simply add it to the devicetree file. That's why I suggested adding the pinmux settings to the pinmux settings of a driver that was getting probed in that previous e2e thread.

    During your debug, you can also check the actual pinmux settings that are applied on your EVM. I provide an example of how to do that here:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1421640/am625-what-is-difference-between-the-pr0_ecap0_in_apwm_out-and-ecap2_in_apwm_out-signals/5521914#5521914 

    Regards,

    Nick