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.

Linux/AM3358: remoteproc remoteproc0: Direct firmware load for /tmp/PRU_LED1.out failed with error -2

Part Number: AM3358

Tool/software: Linux

I'm building custom zImage for AM335x SoC using buildroot... The board is Beagle Bone Black compatible... I'm trying to add PRUSS support. Now I'm stuck at starting the PRU cores.

echo 'start' > /sys/class/remoteproc/remoteproc0/state returns:

[  348.676722] remoteproc remoteproc0: Direct firmware load for /tmp/PRU_LED1.out failed with error -2
[  348.686396] remoteproc remoteproc0: request_firmware failed: -2
[  348.692661] remoteproc remoteproc0: Boot failed: -2

My device tree is attached to the post. I also tried to use am335x-boneblack-pru-adc.dtb with no luck. What can be the problem?

PH8700_7inchLCD_PPSgpio_PRU.7z

  • Please post which Linux version you are using.
  • Here is my dmesg output if needed:

    temp.7z

  • I'm using 4.14.40 linux kernel
  • I've added CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y to the kernel config and now I get:
    [ 74.723499] remoteproc remoteproc0: request_firmware failed: -11
    [ 74.729828] remoteproc remoteproc0: Boot failed: -11
    [ 74.737990] remoteproc remoteproc1: powering up 4a338000.pru
    [ 74.747705] remoteproc remoteproc1: Direct firmware load for /lib/firmware/pru/pps_gen.out failed with error -2
    [ 74.758426] remoteproc remoteproc1: Falling back to user helper
  • I'm using kernel from git://git.ti.com/processor-sdk/processor-sdk-linux.git by the way.
  • Hello Andrey,

    Have you ever successfully loaded and ran PRU firmware before? If not, I would suggest first making sure you understand the process by using a known board (beaglebone black) with known software in a known location (Linux SDK 5.0 and the prebuilt PRU firmware in /lib/firmware) and going through known steps (I suggest the RPMsg Quick Start Guide. The PRU Training: Hands-On Labs are also a good resource).

    If you have already successfully loaded and ran PRU firmware and understand the process, then I can help you debug. Full command line logs (bootup and then the commands you have entered) would be needed at that point.

    Regards,

    Nick

  • Thank you for the reply! I've tried to load zImage-am335x-evm.bin with am335x-boneblack-pru-adc.dtb on my board and the kernel didn't start. Maybe I am using wrong image, I'm using Code Composer 8.3.0 and there is only zImage-am335x-evm.bin in pre-built images. Where can I get pre-built zImage from TI for Beagle Bone Black or zImage-am335x-evm.bin is just fine? Also what should the kernel command line be for that image? Is the following command line: setenv bootargs root=/dev/mmcblk1p2 rw rootwait console=ttyO0,115200 proper? Thanks a lot!)
  • Hello Andrey,

    Linux Processor SDK 5.0 comes with prebuilt images you can use, including kernel image, Linux filesystem, device tree files, and uboot files with the proper boot commands. It also includes a script to place all of those prebuilt files on an SD card for you.

    The documentation to "Download and Install the SDK" is here.

    The documentation for the "Linux SD Card Creation Guide" is here.

    Regards,

    Nick

  • It seems that I figured things out!) The problem was in the following command that I used to set the path to the firmware: echo '/lib/firmware/pru/pps_gen.out' > /sys/class/remoteproc/remoteproc1/firmware. It should be echo '/pru/pps_gen.out' > /sys/class/remoteproc/remoteproc1/firmware (apparently /lib/firmware prefix presents somewhere in the kernel). So now firmware loads fine and the only problem left is that I can't pinmux a pin. I want to use PR1_PRU1_PRU_R30_0 as an output, I've added the following sections to my device tree:

    pruss_pps_pins: pruss_pps_gen_pin {

    pinctrl-single,pins = <0xa0 0x15>;

    };

    pruss_pps_gen {

    compatible = "bone-pinmux-helper";

    status = "okay";

    pinctrl-names = "default";

    pinctrl-0 = <&pruss_pps_pins>;

    };

    But cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep 8a0 shows no changes: pin 40 (PIN40) 44e108a0 0000002f pinctrl-single

    What can be the error in my device tree? I've atteched the full device tree source file below.

    4527.PH8700_7inchLCD_PPSgpio_PRU.7z

  • Just checking: you are setting 0xa0 in your device tree file and "grep"ing for 8a0. Is that intentional?

    Looking into it on my end.

    Regards,
    Nick

  • Update: it looks like you have a pinmux conflict. That pin is getting set for LCD, PRU eth, and now your PRU GPO.

    One of the ways you can check for pinmuxing conflicts is to use the TI PinMux tool. For future readers, the updated version of the tool is here.

    Apparently the current version of the tool (v4.0.1530) has a bug where it is not adding the proper offset to addresses. v4.0.1522 should not have that bug and can be found on the wiki page.

    Regards,

    Nick

  • Thanks for your feedback!) As far as I understood 0xa0 is an offset from pinmux address 0x800 in CPU memory which corresponds to PR1_PRU1_PRU_R30_0 pin, so the PR1_PRU1_PRU_R30_0 pin register address would be 0x8a0, so thus using grep 0x8a0 I am checking the state of that pin's register, so yes it is intentional. Also I was able to solve the problem with device tree using another value in compatible = "bone-pinmux-helper"; parameter. I've changed it to compatible = "ti,omap4-mcspi"; and my pinmux changes have been applied by the kernel. I didn't completely get how compatible parameter works, but my guess is that kernel didn't have a driver for bone-pinmux-helper and thus it refused to apply pinmux changes. Anyway the problem is solved, PRUs work just fine now.
  • Thanks for your feedback!) As far as I understood 0xa0 is an offset from pinmux address 0x800 in CPU memory which corresponds to PR1_PRU1_PRU_R30_0 pin, so the PR1_PRU1_PRU_R30_0 pin register address would be 0x8a0, so thus using grep 0x8a0 I am checking the state of that pin's register, so yes it is intentional. Also I was able to solve the problem with device tree using another value in compatible = "bone-pinmux-helper"; parameter. I've changed it to compatible = "ti,omap4-mcspi"; and my pinmux changes have been applied by the kernel. I didn't completely get how compatible parameter works, but my guess is that kernel didn't have a driver for bone-pinmux-helper and thus it refused to apply pinmux changes. Anyway the problem is solved, PRUs work just fine now.
  • Glad to hear it is working! I am going to close the thread on my side, feel free to respond if we need to continue the discussion on this post.

    Regards,
    Nick