PocketBeagle PRU's not loading in Buildroot Image

[Jaremy Creechley]

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

[Robert Nelson]

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,

--
Robert Nelson
https://rcn-ee.com/

[Jaremy Creechley]

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. :-)

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



Cheers,

[Robert Nelson]

On Fri, Mar 30, 2018 at 3:47 PM, Jaremy Creechley <cree...@gmail.com> wrote:
> 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. :-)
>
> ```
> - compatible = "ti,beaglebone", "ti,beaglebone-black",
> "ti,beaglebone-green";
> ```

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

[Jaremy Creechley]

On Friday, March 30, 2018 at 2:52:18 PM UTC-6, RobertCNelson wrote:

On Fri, Mar 30, 2018 at 3:47 PM, Jaremy Creechley <cree...@gmail.com> wrote:
> 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. :-)
>
> ```
> -       compatible = "ti,beaglebone", "ti,beaglebone-black",
> "ti,beaglebone-green";
> ```

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

Can do.
 

[Robert Nelson]

>> > 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..

[Jaremy Creechley]

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. :-)

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
 

[nibelu...@gmail.com]

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

[nibelu...@gmail.com]

l

[r.rei...@robopec.com]

Hi Jaremy,

On Friday, March 30, 2018 at 10:24:25 PM UTC+2, Jaremy Creechley wrote:

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).

I have been trying to use the BBB PRU through remoteproc with Buildroot but did not managed to get the correct kernel + uboot setup to load the firmware and setup the pinmuxing at boot.

Could you share your buildroot setup or at least which uboot and kernel trees you have used and what changes must be done in their config + the uEnv.txt you ended up using.

Thanks,

Romain

[nibelu...@gmail.com]

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,

[r.rei...@robopec.com]

On Friday, June 15, 2018 at 6:26:02 PM UTC+2, r.rei...@robopec.com wrote:

I have been trying to use the BBB PRU through remoteproc with Buildroot but did not managed to get the correct kernel + uboot setup to load the firmware and setup the pinmuxing at boot.

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.

[mkres...@gmail.com]

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

[Jaremy Creechley]

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

Jaremy Creechley
cree...@gmail.com
το ευαγγελιον

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ci_v6wD_exU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/0f4ed650-b692-4e3f-836e-4df02c22d12f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[aaron.r....@gmail.com]

   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