PocketBeagle PRU's not loading in Buildroot Image

I’m working on creating a variant of a Buildroot image using the 4.9.82-ti-rt kernel (taken from @RCN’s stretch/ sources) and modified to use u-boot overlays. The buildroot image works well on the Beaglebone Green (with the PRU’s loading much quicker than the 4.4.x branch I’d used previously using TI’s recently modified /sys/class/remoteproc/ scheme).

The image also boots the PocketBeagle and loads g_ether and boots fine. However, it does not load the PRU units and only loads remoteproc0 [the omap timer (?)]. There are no /sys/class/remoteproc/ entries for either of the PRU units. The kernel logs don’t show anything, no errors, or anything regard the PRU units (aside from remoteproc0).

Based on the serial output from the BBG, the U-Boot version correctly boots using U-Boot 2018.03. Also, the u-boot based cape manager loads on both the BBG and PB boards after some tweaking with the uEnv.txt file. Still I have not been able to get remoteproc to load the PRU units.

Does anyone have any suggestions? Do I need to load another cape? I’ve tried setting the 4-9 PRU dtbo in uEnv.txt to no avail.

I’ve been reading through the DTS and DTSI sources in the Linux kernel as well as the bb.org-overlays. It seems that the linux in-tree dtsi files for the PocketBeagle don’t mention the PRUSS hardware units at all. This is in contrast to the BBB and BBG which both set the status field to “ok” for both PRU units. My suspicion based on that is that the PRUSS and remoteproc configurations aren’t updated for the PB. The bb.org overlay’s also do not mention the PB at all that I’ve found. However, it appears that several people have the PRU’s loading and working on the PB’s. Hence my confusion!

Thanks, Jaremy

Add this to your pocket beagle dts: (it's essentially what the overlay does..)

&pruss_soc_bus {
        status = "okay";

        pruss: pruss@4a300000 {
                status = "okay";

                pru0: pru@4a334000 {
                        status = "okay";
                };

                pru1: pru@4a338000 {
                        status = "okay";
                };
        };
};

Regards,

Thanks! Was just in the middle of posting that I’d gotten it to work by copying the &pruss_soc_bus section to the pocketbeagle dtsi and deleting the compatible line from the 4-9-pru-load overlay. Not sure which one did the trick…

Question, would it be possible to modify the bb.org overlays to work on the PB’s and would that be the better long term approach? And I noticed the overlays do have various PB support… but where would it be better to add the support or make a patch as the whole kernel/uboot overlay thing confuses me still? I wouldn’t mind creating a PR on github if the overlays would work.

Also, does the “compatible” field actually do anything and where does u-boot get the string name? I read through a bunch of the u-boot code trying to figure it out. :slight_smile:

- compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green";

Cheers,

Thanks! Was just in the middle of posting that I'd gotten it to work by
copying the `&pruss_soc_bus` section to the pocketbeagle dtsi and deleting
the `compatible` line from the 4-9-pru-load overlay. Not sure which one did
the trick...

Question, would it be possible to modify the bb.org overlays to work on the
PB's and would that be the better long term approach? And I noticed the
overlays do have various PB support... but where would it be better to add
the support or make a patch as the whole kernel/uboot overlay thing confuses
me still? I wouldn't mind creating a PR on github if the overlays would
work.

They work on the PB, it was a recent change in our u-boot..

Also, does the "compatible" field actually do anything and where does u-boot
get the string name? I read through a bunch of the u-boot code trying to
figure it out. :slight_smile:

-       compatible = "ti,beaglebone", "ti,beaglebone-black",
"ti,beaglebone-green";

That's for the old kernel overlay manager, just ignore them..

Regards,

Thanks! Was just in the middle of posting that I’d gotten it to work by
copying the &pruss_soc_bus section to the pocketbeagle dtsi and deleting
the compatible line from the 4-9-pru-load overlay. Not sure which one did
the trick…

Question, would it be possible to modify the bb.org overlays to work on the
PB’s and would that be the better long term approach? And I noticed the
overlays do have various PB support… but where would it be better to add
the support or make a patch as the whole kernel/uboot overlay thing confuses
me still? I wouldn’t mind creating a PR on github if the overlays would
work.

They work on the PB, it was a recent change in our u-boot…

Ah, gotcha. To clarify, the PRU’s are working or just the overlays? Then, can I just pull in a more recent u-boot and not need to patch anything and if so is that on the main u-boot repo? Currently I’m using u-boot 2018.03…

Also, does the “compatible” field actually do anything and where does u-boot
get the string name? I read through a bunch of the u-boot code trying to
figure it out. :slight_smile:

- compatible = "ti,beaglebone", "ti,beaglebone-black",
"ti,beaglebone-green";

That’s for the old kernel overlay manager, just ignore them…

Can do.

> Question, would it be possible to modify the bb.org overlays to work on
> the
> PB's and would that be the better long term approach? And I noticed the
> overlays do have various PB support... but where would it be better to
> add
> the support or make a patch as the whole kernel/uboot overlay thing
> confuses
> me still? I wouldn't mind creating a PR on github if the overlays would
> work.

They work on the PB, it was a recent change in our u-boot..

Ah, gotcha. To clarify, the PRU's are working or just the overlays? Then,
can I just pull in a more recent u-boot and not need to patch anything and
if so is that on the main u-boot repo? Currently I'm using u-boot 2018.03..

Yes, in our U-Boot, I recently enabled PRU overlay support for PB's.

Pure "mainline" supports the infrastructure to support overlays..

However a "cape/overlay" manager is not in u-boot mainline..

Thus we use this hack..

The hack was a quick way to test things..

Regards,

Question, would it be possible to modify the bb.org overlays to work on
the
PB’s and would that be the better long term approach? And I noticed the
overlays do have various PB support… but where would it be better to
add
the support or make a patch as the whole kernel/uboot overlay thing
confuses
me still? I wouldn’t mind creating a PR on github if the overlays would
work.

They work on the PB, it was a recent change in our u-boot…

Ah, gotcha. To clarify, the PRU’s are working or just the overlays? Then,
can I just pull in a more recent u-boot and not need to patch anything and
if so is that on the main u-boot repo? Currently I’m using u-boot 2018.03…

Yes, in our U-Boot, I recently enabled PRU overlay support for PB’s.

Pure “mainline” supports the infrastructure to support overlays…

However a “cape/overlay” manager is not in u-boot mainline…

Thus we use this hack…

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.03/0002-U-Boot-BeagleBone-Cape-Manager.patch

The hack was a quick way to test things…

Odd, I’m using that particular patch (and the 0001-am335x_evm*.patch). With it, I was getting the /sys/devices/platform/cape_mgr to show up when I setup uEnv.txt to enable the cape_mngr. Though without the slots, I’m not sure how it’s supposed to work. :slight_smile:

I then tried setting the uboot_overlay_pru to a few of the PRU overlays, but didn’t get pru’s to work… Was I missing something maybe? I don’t have systemd to configure anything after boot, just using the sysfs and PRU/RPROC support compiled into the kernel.

Thanks for the help btw! I realize the PB’s are still relatively new and not everything has been upstreamed yet…

Cheers, Jaremy

Hi,

I have the exact same problem.
I am using the PocketBeagle and the newest image “Debian 9.3 2018-03-05 4GB SD IoT”.

When using this image on BeagleBone, everything is working normally, with dmesg I can see that both PRUs are booted successfully, and also I tried to used them with success.

Now I am migrating from BeagleBone to the PocketBeagle with the same image. But here the PRUs are not booted at all, the folder /sys/class/remoteproc1 and /sys/class/remoteproc2 are missing ! (not a case with BeagleBone)

You wrote to add &pruss_soc_bus to the .dtsi file. But which file exactly?
The am335x-pocketbeagle-common.dtsi or ?
I tried to add this part of code to the am335x-pocketbeagle-common.dtsi and also to am335x-pocketbeagle.dts and I used “make src/arm/am335x-pocketbeagle.dtb” to update the changes but nothing helps. The PRUs want boot.

Help!

Kind Regards,
Ivan

Dana petak, 30. ožujka 2018. u 22:37:42 UTC+2, korisnik RobertCNelson napisao je:

l

Dana petak, 30. ožujka 2018. u 22:24:25 UTC+2, korisnik Jaremy Creechley napisao je:

Hi Jaremy,

For me worked simple change in the uEnv.txt file

I changed from:
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo

to:
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo

I am using debian image 9.3(4.9.82-ti-r102)

Regards,

For info, I’ve managed to get the PRU with remoteproc working on Buildroot by compiling the required modules directly built-in the kernel (‘y’ option in kconfig) and not as modules (‘m’ option in kconfig) because I did not manage to get them loaded automatically.

Hello PRU experts,

Newcomers like myself struggle getting the PRUs enabled on PocketBeagle.

(1) I’ve downloaded the image Debian 9.4 2018-06-17 4GB SD IoT from website (https://beagleboard.org/latest-images)

Do we have steps of what to do from this clean installion point, that would allow me to toggle a GPIO pin using a PRU?

Many Thanks,
Brijen

It’s easiest to start off with the uboot overlay setup:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

And configure the pins as PRU pins:

http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/

Best, Jaremy

I am also struggling to get an encoder working on PRU0 / QEP0 on the PocketBeagle. Like Brijen, the walkthroughs posted are geared toward the BeagleBone Black and Blue, which appear to work well out-of-the-box. I am running the latest "Debian 9.5 2018-10-07 4GB SD IoT " release. Then, walked through the two links provided by Jaremy.
My encoder A and B signals are connected to PocketBeagle pins P1-31 (QEP0 A) and P2-24 (QEP0 B). Then I run the following:

debian@beaglebone:~$ config-pin P1_31 qep
debian@beaglebone:~$ config-pin P2_34 qep
debian@beaglebone:~$ config-pin -q P2_34
P2_34 Mode: qep
debian@beaglebone:~$ config-pin -q P1_31
P1_31 Mode: qep
debian@beaglebone:~$ ls /sys/devices/platform/ocp/48300000.epwmss/
48300200.pwm driver driver_override modalias of_node power subsystem uevent

Note that the ‘48300180.eqep/’ directory isn’t there, even though the pins appear to be in QEP mode. I feel I’m missing something simple, ideas on what it may be?

Thanks,
Aaron