• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 103 subscribers
  • Views 1644 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.

Cannot find the file "virtio.ko" "virtio_ring.ko" and "remoteproc.ko"

YangYu
Intellectual 330 points

I'm learning about pru programming. And I'm going through Lab4 in the  PRU Training: Hands-on Labs . I've followed the instruction to install SDK( AM335X 8.0 ) and apply the patches to the SDK successfully. I've configured the remoteproc as a module. Then I builded the kernel and builded the kernel modules.

Now, according to the instruction, I should copy the below modules to the rootfs partition of my SD card.

1. drivers/virtio/virtio.ko

2. drivers/virtio/virtio_ring.ko

3. drivers/rpmsg/virtio_rpmsg_bus.ko

4. drivers/remoteproc/remoteproc.ko

5. drivers/remoteproc/pruss_remoteproc.ko

But I can only find the 3 and 5, I cannot find the file 1, 2 and 3.

I want to know what's the problem. Do I need to do some other configuration before build kernel and modules?

BTW, If I want to use the TI C/C++ compiler to build my PRU C code and load it as a firmware in my Beaglebone Black, is there any other way to  achieve my goal? Can I get a binary file via the C compiler in CCS, and then use a linux program run on the arm to load the binary file on the PRU, just like the assembler's does? If this is possible, how to do it.

Thanks a lot.

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the PRU experts to look at this.
  • 0
    TI__Genius 10415 points

    user4437392,

    Beginning with SDK 8.0 you only need to copy, and then later insert, modules number 3 and 5 ('drivers/rpmsg/virtio_rpmsg_bus.ko' and 'drivers/remoteproc/pruss_remoteproc.ko'). This is due to the fact that the other 3 modules are already included and inserted by default in the 3.14 kernel of the newer SDKs.

    I've updated the Lab 4 instructions on the wiki page to reflect this change:

    I think your other questions will be addressed when you continue through the remainder of Lab 4 but here are some responses:

    • Yes you can use the TI C/C++ compiler/linker to build your PRU C code (this is what CCS uses when you build PRU projects)
    • The PRU C compiler/linker will generate a .out file that you can load as a firmware into the PRU cores. In CCS this file will most likely be found in a folder named 'Debug' or 'Release' that will be generated by CCS
    • When you insert the 'pruss_remoteproc.ko' module it looks for two firmware images in the /lib/firmware directory of the device named rproc-pru0-fw and rproc-pru1-fw. It then loads these fimwares into their respective PRU cores and runs the PRU
      • You can take the .out file that the PRU C compiler/linker generates and rename it to rproc-pruX-fw (where X is 0 or 1) and then place it in the /lib/firmware directory to have the pruss_remoteproc module load and run the firmware for you

    Let me know if you have any other questions,

    Jason Reeder

  • 0 in reply to Jason Reeder
    Intellectual 330 points
    Thanks for your replying. Actually, I can get a .out file from the PRU C compiler/linker and I'm wondering if I can get a .bin file from the PRU C compiler/linker. If I can, then how to do it.
    The reason I want to get a .bin file is that I always have trouble in changing the system kernel on my Beaglebone Black board. So I think if I can get a .bin file, then I can use a program run on ARM to load this .bin file into PRU core without changing the system kernel, just like the way to use Assembly compiler.
    The problem I'm facing when I change the kernel is that my ubuntu host PC cannot recognize my board after the kernel is changed and the board booted. I can get the information that my board surely booted via a serial port and minicom tool. But I found that I can't get even a MAC addr of the beaglebone black board when I type in the command 'ifconfig' in the minicom. I was quite confused, I was doing such work for several times but facing the same problem.
    The SD card in my board is using the filesystem named "Angstrom", and files I changed are as follow:
    1. I deleted the original kernel file and the symlink "zImage", and copyed the "zImage.pru" to the boot folder then created a symlink "zImage" to point to the "zImage.pru".
    2. I deleted all the dtb file in the /boot file and added the file "am335x-boneblack-prucape.dtb" then created a symlink to point to the "am335x-boneblack-prucape.dtb".
    3. I deleted the whole "/modules" folder in the "/lib" and then add the "/modules" that the SDK applyed the PRU patches generated.
    Is there any wrong about what I was doing?
    Thank you very much!
  • 0 in reply to YangYu
    TI__Genius 10415 points
    Are you following the kernel build procedure found here: processors.wiki.ti.com/.../Linux_Kernel_Users_Guide

    Have you been successful in getting Lab 4 completed? If so, then you should be able to use that procedure to load .out files into the PRUs without having to change your kernel or use .bin files.

    Jason Reeder
  • 0 in reply to YangYu
    Prodigy 185 points

    With regards to your USB issues, I had a similar issue when loading the 3.14 kernel from TI onto an existing BBB image but I was able to solve it.

    Running "dmesg" I discovered that the USB drivers weren't being loaded. It was looking in /lib/modules/3.14.26-g121ca2a but I had installed the modules into /lib/modules/3.14.26-g121ca2a-dirty which I got from my kernel source/include/generated/utsrelease.h which is also what I used for Uboot. Anyway, all I had to do to fix the problem was create a symbolic link in /lib/modules so that the kernel knew where the drivers were.

    root@beaglebone:/lib/modules# ls -s 3.14.26-g121ca2a-dirty 3.14.26-g121ca2a

    reboot and the USB worked.