Unable to find remote_proc in the latest kernel build image

[smblkchevy]

I am doing the kernel build from what I think is Robert's latest from git.

This is https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-rt-4.9.y.

I do the build in a Debian Jessie Virtual Box image.

I just do the build_deb.sh script and I get the following in the deploy folder:

linux-libc-dev_1cross_armhf.deb

linux-headers-4.9.32-ti-rt-r41_1cross_armhf.deb

linux-firmware-image-4.9.32-ti-rt-r41_1cross_armhf.deb

linux-image-4.9.32-ti-rt-r41_1cross_armhf.deb

I use FileZilla and copy the 4 files to the /var/cache/apt/archives folder on the Beaglebone Green.

I then do the following:

sudo dpkg -i linux-libc-dev_1cross_armhf.deb

sudo dpkg -i linux-headers-4.9.32-ti-rt-r41_1cross_armhf.deb

sudo dpkg -i linux-firmware-image-4.9.32-ti-rt-r41_1cross_armhf.deb

sudo dpkg -i linux-image-4.9.32-ti-rt-r41_1cross_armhf.deb

It looks like everything installs properly except for a couple of driver issues in the linux image looks like they relate to temperature drivers.

I do a reboot 

and

the uname -a is this

Linux beaglebone 4.9.32-ti-rt-r41 #1 SMP PREEMPT RT Fri Jun 23 11:59:11 EDT 2017 armv71 GNU/Linux

When I do the lsmod this is what I'm seeing

Module                                Size     Used by

omap_aes_driver              23718    0

crypto_engine                     7035    1  omap_aes_driver

omap_sham                      26574    0

omap_rng                            5544    0

rng_core                              8523    1  omap_rng

usb_f_acm                           8217    1

u_serial                               12927   3  usb_f_acm

usb_f_rndis                         25931    1

g_multi                                  5958    0

usb_f_mass_storage           50190    2  g_multi

u_ether                                 13883   2  g_multi,usb_f_rndis

libcomposite                         54819   4  usb_f_acm,usb_f_mass_storage,g_multi,usb_f_rndis

cpufreq_ondemand                7899   1

cpufreq_userspace                 3807   0

cpufreq_conservative             4417   0

cpufreq_powersave                1567   0

evdev                                     13460  1

tps65217_charger                   5088   0

uio_pdrv_genirq                       4045   0

uio                                          10625   1  uio_pdrv_genirq

A few months ago I was running the remote_proc to the PRUs on a pre-built version I think it was somewhere in the V4.1 range but without the PREEMPT_RT.

I wanted to test my PRU code on a PREEMPT build but this is the only way I could figure out to do it.

Is there something I'm missing when I do the build to enable the remote_proc.  The only change I made in the menu_config was to enable the remote_proc, I think it was in the drivers section.

The modprobe pru_rproc and the rmmod pru_rproc are no longer functional in this version.

Here is what's in the dmesg

root@beaglebone:/var/lib/cloud9# dmesg | grep pru

[    3.716208] ti-pruss 4a300000.pruss: creating PRU cores and other child platform devices

[    3.751488] irq: no irq domain found for /ocp/pruss_soc_bus@4a326000/pruss@4a300000/intc@4a320000 !

[    3.761517] irq: no irq domain found for /ocp/pruss_soc_bus@4a326000/pruss@4a300000/intc@4a320000 !

[    3.772938] remoteproc remoteproc1: 4a334000.pru0 is available

[    3.778990] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a334000 probed successfully

[    3.791078] remoteproc remoteproc2: 4a338000.pru1 is available

[    3.797109] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a338000 probed successfully

root@beaglebone:/var/lib/cloud9# 

Any help here is greatly appreciated

Thanks,

[Igor Jędrzejczak]

Hi, I am experiencing the exact same problem... How you found a fix already?

[Igor Jędrzejczak]

Have*

[eryk.dru...@gmail.com]

Good day,

By now you probably already found an answer/solution, but I had a similar problem with kernel 4.9.51 and maybe someone else needs the workaround.

It looks like now the firmware has to be loaded into the PRU's manually. 

http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg

echo 'am335x-pru0-fw' > /sys/class/remoteproc/remoteproc1/firmware 
echo 'am335x-pru1-fw' > /sys/class/remoteproc/remoteproc2/firmware 
echo 'start' > /sys/class/remoteproc/remoteproc1/state 
echo 'start' > /sys/class/remoteproc/remoteproc2/state 

After executing the above commands I would get the familiar dmesg output:

[  100.724488] remoteproc remoteproc1: powering up 4a334000.pru0

[  100.734584] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 26416

[  100.748630] remoteproc remoteproc1: remote processor 4a334000.pru0 is now up

[  111.235625] remoteproc remoteproc2: powering up 4a338000.pru1

[  111.247976] remoteproc remoteproc2: Booting fw image am335x-pru1-fw, size 72904

[  111.261356] ti-pruss 4a300000.pruss: configured system_events = 0x00000000000c0000 intr_channels = 0x0000000a host_intr = 0x0000000a

[  111.285770] remoteproc remoteproc2: registered virtio0 (type 7)

[  111.300130] remoteproc remoteproc2: remote processor 4a338000.pru1 is now up

[  111.380517] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1f

[  111.388129] virtio_rpmsg_bus virtio0: rpmsg host is online

[  111.544072] rpmsg_pru virtio0.rpmsg-pru.-1.31: new rpmsg_pru device: /dev/rpmsg_pru31

Hope this helps,

Eryk

On Wednesday, July 12, 2017 at 5:55:14 AM UTC-4, Igor Jędrzejczak wrote:

Have*