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, 

On Friday, March 30, 2018 at 2:37:42 PM UTC-6, RobertCNelson wrote:
>
> On Fri, Mar 30, 2018 at 12:56 AM, Jaremy Creechley <[email protected] 
> <javascript:>> 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). 
> > 
> > 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! 
>
> 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/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f6de5878-9c59-43a5-a068-58d13f2257d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to