Enabling BBB PRUSS in dtb-rebuilder 3.14?

GoogleGroups
1

It seems that the PRUs are not enabled by default in the BeagleBone Black's dts files, right? And to enable it, I think I need to add something like this (taken from the x15.dts). Thing is, all that mailbox stuff makes me nervous, and I'm not sure the addresses are correct for the 3358, etc.

&pruss1 {
  status = "okay";
  pru1_0: pru@4b234000 {
    mboxes = <&mailbox3 &mbox_pru1_0>;
    status = "okay";
  };

  pru1_1: pru@4b238000 {
    mboxes = <&mailbox3 &mbox_pru1_1>;
    status = "okay";
  };
};

Robert, can you show me the correct bits to enable the PRUs?

Thanks!

2

They are actually enabled:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am33xx.dtsi#L761

on bootup, they look for a few firmware files:

dmesg | grep remote

Regards,

3

They are actually enabled:

dtb-rebuilder/src/arm/am33xx.dtsi at 3.14-ti · RobertCNelson/dtb-rebuilder · GitHub

Oh, I didn't see a status="okay" line, so I thought maybe they were disabled. The problem I'm having is that /dev/uioX doesn't exist, and the libprussdrv library I'm using is failing to open it (the host interrupt).

Instructions I've seen tell me to:

# modprobe uio_pruss
FATAL: Module uio_pruss not found.

But you can see, that's not found. What am I missing? Is that module not in the distro by default?

Finally, it seems to fail to load the firmware:

dmesg | grep remote

[ 2.780145] remoteproc0: 4a334000.pru0 is available
[ 2.780159] remoteproc0: Note: remoteproc is still under development and considered experimental.
[ 2.780168] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 2.780439] remoteproc0: failed to load rproc-pru0-fw
[ 2.788152] remoteproc0: powering up 4a334000.pru0
[ 2.788228] remoteproc0: request_firmware failed: -2
[ 2.799717] remoteproc1: 4a338000.pru1 is available
[ 2.799731] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 2.799740] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 2.799968] remoteproc1: failed to load rproc-pru1-fw
[ 2.805679] remoteproc1: powering up 4a338000.pru1
[ 2.805751] remoteproc1: request_firmware failed: -2
[ 2.879535] remoteproc2: wkup_m3 is available
[ 2.879554] remoteproc2: Note: remoteproc is still under development and considered experimental.
[ 2.879563] remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 2.880691] remoteproc2: powering up wkup_m3
[ 2.883576] remoteproc2: Booting fw image am335x-pm-firmware.elf, size 219827
[ 2.884295] remoteproc2: remote processor wkup_m3 is now up

4

So, yeah, it seems uio_pruss is missing from the 3.14.26-ti-r43 kernel I have built. Is remoteproc supposed to replace uio_pruss? Can I build uio_pruss and use it in 3.14? I've got a third-party library dependent on it. I see the code in the linux kernel source I have, but I don't know how to build just that module.

Thanks!

5

remoteproc just loads the firmware and set's up the initial interface.

I wish i could find some documents on TI's pages showing how we are
suppost to use the interface in their v3.14-ti tree. It is tailored
for mainline...

Regards,

6

Is the fact that my dmesg showing a failure to load firmware a problem? I thought the way you used the PRU was to load the firmware you wrote at the time you want to use it.

I've enable CONFIG_UIO_PRUSS in the kernel you had me build a while back (dealing with the USB audio issues), and am re-building that. Hopefully I won't completely bork what I have going on.

7

remoteproc just loads the firmware and set's up the initial interface.

Is the fact that my dmesg showing a failure to load firmware a problem? I thought the way you used the PRU was to load the firmware you wrote at the time you want to use it.

That's firmware for your to create. If you copy your pru firmware to
/lib/firmware/ with those two file names it'll load it..

I've enable CONFIG_UIO_PRUSS in the kernel you had me build a while back (dealing with the USB audio issues), and am re-building that. Hopefully I won't completely bork what I have going on.

I thought i had that enabled in v3.14.x

Regards,

8

Doesn't seem like it:

$ ./scripts/config --state CONFIG_UIO_PRUSS
undef

Also, I tried enabling it, then re-ran the fakeroot make command (with a new local version name), and tried installing those .debs, but I still don't have a uio_pruss module or the /dev/uio devices. I actually used --enable, not --module, so I didn't expect it to build a module, but I don't have /dev/ui*, so I'm not sure what I'm supposed to do.

I then tried changing the config to --module, re-ran the fakeroot make, but I still didn't get a module built. Then I checked the state again, and it's "undef" again. Something is unsetting it?

9

Rick Mann <rmann@...> writes:

>
>>
>>>
>>> remoteproc just loads the firmware and set's up the initial

interface.

>>
>> Is the fact that my dmesg showing a failure to load firmware a

problem? I thought the way you used the PRU was

to load the firmware you wrote at the time you want to use it.
>
> That's firmware for your to create. If you copy your pru firmware to
> /lib/firmware/ with those two file names it'll load it..
>
>> I've enable CONFIG_UIO_PRUSS in the kernel you had me build a while

back (dealing with the USB audio

issues), and am re-building that. Hopefully I won't completely bork

what I have going on.

>
> I thought i had that enabled in v3.14.x

Doesn't seem like it:

$ ./scripts/config --state CONFIG_UIO_PRUSS
undef

Also, I tried enabling it, then re-ran the fakeroot make command (with

a new local version name), and tried

installing those .debs, but I still don't have a uio_pruss module or

the /dev/uio devices. I actually used

--enable, not --module, so I didn't expect it to build a module, but I

don't have /dev/ui*, so I'm not sure

what I'm supposed to do.

I then tried changing the config to --module, re-ran the fakeroot

make, but I still didn't get a module

built. Then I checked the state again, and it's "undef" again.

Something is unsetting it?

I am experiencing the same problems with PRU on 3.14 kernel. Has some
progress been made? Thanks

10

I think I ended up downgrading to the 3.8 kernel. Haven't tried since January.

11

Elias Bakken cleaned up pru support in v4.1.x for his Replicape

Regards,

12

Hi,

I am getting exactly same issue. Did you find solution to this problem? How should I enable PRU?

-Anuja

13

Instead of randomly replying to an ancient message, why don't you
actually state your "error" and what you are trying to do..

hint...

This is fixed in 4.1.x/etc..

Regards,