[beagleboard] PRU Assumptions - True or False

[Bruce Chidester]

I am using BBB Revision C

Please help me get clarity on my assumptions that I believe I have learned 
so far and tell me where I am incorrect:

1. There are 2 architectures to interact with the PRU's. They are *UIO* and 
*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt file. 
You cannot run both at the same time.

2. When using RemoteProc you can *send* a remote message to the PRU and 
this solution *does not work* with UIO.

3. When using UIO the PRU can *send* an Interrupt to the host code but 
RemoteProc *cannot*.

4. When using UIO, you *cannot* send an interrupt to the PRU, you need to 
create some other solution maybe through shared memory.

5. When working with UIO, clpru generated binaries are *no good* and this 
forces you to write the PRU code in assembly and to use pasm.

It's really not knowing which architecture some articles are talking about, 
or not knowing the limits of the architecture that makes the PRU stuff so 
frustrating.

I thank you in advance.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4dfa88bc-372e-4cc5-95fa-edc0b1dd6d98n%40googlegroups.com.

[beagleboard] PRU Messaging

[Bruce Chidester]

Group,

I have been attempting to make a messaging example and I am either very 
close or so far away I don't realize it since I cannot seem to get it to 
respond.

Once I get it working I will leave the answer for the world, please help me 
get this example working.

It is at: https://gitlab.com/brucechidester/pru-messaging-example

In summary, it is the smallest possible example where the application code 
sends an interrupt (or message) to the PRU and the PRU sends an interrupt 
every second (with a GPIO pulse). Every time the pulse is sent from the 
PRU, the main application prints a message.

Thanks in advance.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6a371767-2ae2-4ee8-ae8b-eed2d9aebca9n%40googlegroups.com.

Re: [beagleboard] PRU remoteproc1 and 2 missing

[Cheng Chen]

It works. Thanks for the help! Appreciate it

Regards,
Cheng

在2021年4月7日星期三 UTC-4 下午1:20:20 写道：

> On Wed, Apr 7, 2021 at 11:31 AM Cheng Chen  wrote: 
> > 
> > Hi, 
> > 
> > I am just learning Beaglebone and have set up a Debian 10 image on a 
> recently purchased Beaglebone Black wireless. 
> > I am following the Molloy's book chapter 15 to learn PRU. 
> > However, it seems rproc module has not loaded the PRU. 
> > Is there an additional step to allow use of the PRUs? What should I look 
> at to debug this issue? Thanks in advance. 
> > 
> > Attached is the /opt/scripts/tools/version.sh output 
> > 
> > git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46] 
> > eeprom:[A335BNLTBWA51824BBWG0190] 
> > model:[TI_AM335x_BeagleBone_Black_Wireless] 
> > dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06] 
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g07d5700e21]:[location: dd MBR] 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2016.11-rc3-2-g73df7f]:[location: dd MBR] 
>
> U-Boot is too old, please run: 
>
> ``` 
> sudo apt update 
> sudo apt install bb-u-boot-am335x-evm 
> cd /opt/u-boot/bb-u-boot-am335x-evm/ 
> sudo ./install.sh 
> sudo reboot 
> ``` 
>
> > UBOOT: Booted Device-Tree:[am335x-boneblack-wireless.dts] 
> > kernel:[4.19.94-ti-r42] 
>
> Kernel is too old, please run: 
>
> ``` 
> sudo /opt/scripts/tools/update_kernel.sh 
> ``` 
>
> > pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403 
>
> too old: 
>
> ``` 
> sudo apt install --only-upgrade bb-cape-overlays bb-customizations 
> ``` 
>
> Finally , reboot, everything should now work.. 
>
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d3fd4bcf-cd77-496a-89e7-71e489ddc0e3n%40googlegroups.com.

Re: [beagleboard] PRU remoteproc1 and 2 missing

[Robert Nelson]

On Wed, Apr 7, 2021 at 11:31 AM Cheng Chen  wrote:
>
> Hi,
>
> I am just learning Beaglebone and have set up a Debian 10 image on a recently 
> purchased Beaglebone Black wireless.
> I am following the Molloy's book chapter 15 to learn PRU.
> However, it seems rproc module has not loaded the PRU.
> Is there an additional step to allow use of the PRUs? What should I look at 
> to debug this issue? Thanks in advance.
>
> Attached is the /opt/scripts/tools/version.sh output
>
> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
> eeprom:[A335BNLTBWA51824BBWG0190]
> model:[TI_AM335x_BeagleBone_Black_Wireless]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g07d5700e21]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2016.11-rc3-2-g73df7f]:[location: dd MBR]

U-Boot is too old, please run:

```
sudo apt update
sudo apt install bb-u-boot-am335x-evm
cd /opt/u-boot/bb-u-boot-am335x-evm/
sudo ./install.sh
sudo reboot
```

> UBOOT: Booted Device-Tree:[am335x-boneblack-wireless.dts]
> kernel:[4.19.94-ti-r42]

Kernel is too old, please run:

```
sudo /opt/scripts/tools/update_kernel.sh
```

> pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403

too old:

```
sudo apt install --only-upgrade bb-cape-overlays bb-customizations
```

Finally , reboot, everything should now work..

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhzF%3D7EMCXMCJNAb_n%3De56_1_RGqmexb95K1DUkW2MDAQ%40mail.gmail.com.

[beagleboard] PRU remoteproc1 and 2 missing

[Cheng Chen]

Hi, 

I am just learning Beaglebone and have set up a Debian 10 image on a 
recently purchased Beaglebone Black wireless. 
I am following the Molloy's book chapter 15 to learn PRU. 
However, it seems rproc module has not loaded the PRU.
Is there an additional step to allow use of the PRUs? What should I look at 
to debug this issue? Thanks in advance.

Attached is the /opt/scripts/tools/version.sh output

git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTBWA51824BBWG0190]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2016.11-rc3-2-g73df7f]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-wireless.dts]
kernel:[4.19.94-ti-r42]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 
rng_core.default_quality=100 quiet]
dmesg | grep remote
[   48.299247] Bluetooth: hci0: change remote baud rate command in firmware
[   51.242110] remoteproc remoteproc0: wkup_m3 is available
[   51.258161] remoteproc remoteproc0: powering up wkup_m3
[   51.258191] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[   51.258458] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[0.836673] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[0.838338] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e00b59c6-4c5c-4066-a06b-5d2698c01968n%40googlegroups.com.

[beagleboard] PRU I/O max speed

[Paul Beam]

I am, unfortunately, bit-banging SPI with the PRU, and I seem to be running 
into a speed limit < 50 MHz I desire.  I can certainly create a clock that 
fast, but reading data seems to be delayed.  I can see on the logic 
analyzer a "0" clearly being read as a '1" so there is either a delay in my 
clock output or a delay in my input or both.  I would like to think that 
r30 and r31 are tied directly to the outside world, but now I am thinking 
there is something in between that is either clocked or just has 
significant output delays.  Anyone else encountered this?  

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cad28722-32c5-4d82-ba49-325843aecb87n%40googlegroups.com.

[beagleboard] PRU RemoteProc documentation

[Fisher Grubb]

Hi all,

I've done a few searches and couldn't find any threads or "conversations" 
in this forum/group on the remoteproc kernel module for loading firmware 
onto the PRUs.

The remoteproc framework is supposed to be a Linux standard, there are some 
generic documents for it, but I've only found a general diagram and 
explanation in TIs SDK docs for their implementation.

Simple code to flash LEDs loads and runs fine, but larger, more complicated 
code that also just flashes LEDs fails to load, occasionally parts of it 
run, or none of it runs and the there's a bit of a stack trace in dmesg.

The first line of the error in dmesg is:
4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At 
Address: 0x00806664 : Data Access in Supervisor mode during Functional 
access

Is this resource_table related?  Or its meaning that there's a strange 
memory access?


I'm trying to find out:

   1. How to get verbose info that shows what the pru_rproc kernel module 
   is doing
   2. How to configure it, maybe commandline, or through the sysfs
   3. Documentation of how it functions, and what it expects, such as the 
   resource_table and firmware layout to match, how it handles errors etc.

Thanks,
Fisher

Here's my dmesg:

[   76.711182] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   76.736257] IPv6: ADDRCONF(NETDEV_CHANGE): usb1: link becomes ready
[   77.894970] NOHZ: local_softirq_pending 08
[   77.903344] NOHZ: local_softirq_pending 08
[   77.923339] NOHZ: local_softirq_pending 08
[   77.967346] NOHZ: local_softirq_pending 08
[   77.977416] NOHZ: local_softirq_pending 08
[   78.009731] NOHZ: local_softirq_pending 08
[   78.227509] NOHZ: local_softirq_pending 08
[   78.414768] NOHZ: local_softirq_pending 08
[   78.478154] NOHZ: local_softirq_pending 08
[   78.483369] NOHZ: local_softirq_pending 08
[  139.787136] remoteproc remoteproc6: powering up 4b2b4000.pru
[  139.792152] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, size 
32644
[  139.792176] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  152.475360] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  207.719337] pru-rproc 4b2b4000.pru: can't provide a NULL firmware
[  234.455246] remoteproc remoteproc6: powering up 4b2b4000.pru
[  234.455834] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369696
[  234.455878] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  241.915304] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  254.522378] remoteproc remoteproc6: powering up 4b2b4000.pru
[  254.522557] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, size 
32644
[  254.522577] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  257.559216] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  375.451166] remoteproc remoteproc6: powering up 4b2b4000.pru
[  375.451886] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369696
[  375.451931] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  380.203249] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  387.895263] remoteproc remoteproc6: powering up 4b2b4000.pru
[  387.895392] remoteproc remoteproc6: Booting fw image PRU-LEDs.out, size 
32644
[  387.895411] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  390.959144] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  407.879207] remoteproc remoteproc6: powering up 4b2b4000.pru
[  407.879755] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369696
[  407.879800] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  425.139157] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  628.915190] remoteproc remoteproc6: powering up 4b2b4000.pru
[  628.915736] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
369876
[  628.915780] remoteproc remoteproc6: remote processor 4b2b4000.pru is now 
up
[  840.639171] pru-rproc 4b2b4000.pru: can't change firmware while running
[  845.259199] remoteproc remoteproc6: stopped remote processor 4b2b4000.pru
[  852.903126] remoteproc remoteproc6: powering up 4b2b4000.pru
[  852.903663] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
370028
[  852.903716] [ cut here ]
[  852.903735] WARNING: CPU: 0 PID: 1810 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x368/0x3a4
[  852.903744] 4400.ocp:L3 Standard Error: MASTER PRUSS2 PRU1 TARGET 
PCIE1 (Read): At Address: 0x00806664 : Data Access in Supervisor mode 
during Functional access
[  852.903750] Modules linked in: rpmsg_rpc rpmsg_proto pru_rproc 
pruss_intc bnep pruss pvrsrvkm(O) pruss_soc_bus ti_vpe ti_sc 
videobuf2_dma_contig ti_csc ti_vpdma v4l2_mem2mem v4l2_common 
videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media btsdio 
bluetooth joydev ecdh_generic brcmfmac stmpe_adc brcmutil cfg80211 
omap_remoteproc virtio_rpmsg_bus rpmsg_core usb_f_ncm 

Re: [beagleboard] PRU 2 0 memory addresses

[Vinicius Juvinski]

Hi Mark,


My main question is how to use the offsets.
How 0x0002_2000 will become 0x4B2A2000?


For instance on the documents the
Em seg., 4 de jan. de 2021 às 18:55, 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> escreveu:

> Please rephrase the question
>
> You said you used AM5729 addresses on BBC and BIG this will confuse people.
>
> You also said you find this below in code. It's possible that's an offset
> only
> #define RCOUT_PRUSS_RAM_BASE  0x4b28
>
> Stick what's in the reference manual and then verify that with any code
> accessing area you need as a cross check
>
> Find the offset in manual cross check software offsets is my suggestion
>
> Mark
>
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Sun, Jan 3, 2021 at 9:47 PM, Vinicius Juvinski
>  wrote:
> Hi guys,
>
> today to load the a code to PRU on BBB, BBG and Pocket we are using this
> addresses:
>
> POCKET:
> #define RCIN_PRUSS_RAM_BASE   0x4a301000
> #define RCOUT_PRUSS_RAM_BASE 0x4a30
> #define RCOUT_PRUSS_CTRL_BASE 0x4a322000
> #define RCOUT_PRUSS_IRAM_BASE 0x4a334000
>
> BBB:
> #define RCIN_PRUSS_RAM_BASE   0x4a303000
> #define RCOUT_PRUSS_RAM_BASE 0x4a302000
> #define RCOUT_PRUSS_CTRL_BASE 0x4a324000
> #define RCOUT_PRUSS_IRAM_BASE 0x4a338000
>
> Anyone please help me in what is the addresses for PRU2_0 for this
> addresses ? I tried all the addresses I found at AM5729 Reference manual
> and digging the filesystem I achived this addresses:
> #define RCOUT_PRUSS_RAM_BASE  0x4b28
> #define RCOUT_PRUSS_CTRL_BASE 0x4b24000
> #define RCOUT_PRUSS_IRAM_BASE 0x4b2b4000
> #define RCIN_PRUSS_RAM_BASE   0x4b281000
>
> But or the beagle freeze or there are sigbus error. I create a custom dtb
> and all pins are as expected.
>
> Thanks for your help
>
>
>
> This is the version script:
>
> root@beaglebone:~/ardupilot# /opt/scripts/tools/version.sh
> git:/opt/scripts/:[fa783d879c7ae9986f2d97977a8f8987bb16f72e]
> model:[BeagleBoard.org_BeagleBone_AI]
> dogtag:[BeagleBoard.org Debian Buster IoT TIDL Image 2020-11-30]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL
> 2020.10-rc1-1-gc5bc0aaa70 (Aug 24 2020 - 16:42:42 -0500)]:[location: dd
> MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL
> 2020.10-rc1-1-gc5bc0aaa70 (Aug 24 2020 - 16:42:42 -0500)]:[location: dd
> MBR]
> kernel:[4.14.108-ti-r137]
> nodejs:[v10.21.0]
> device-tree-override:[dtb=am572x-juva1.dtb]
> /boot/uEnv.txt Settings:
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade
> ]
> pkg:[bb-cape-overlays]:[4.14.20201221.0-0~buster+20201221]
> pkg:[bb-customizations]:[1.20201105.0-0~buster+20201110]
> pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
> pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
> pkg:[kmod]:[26-1]
> pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video
> plugdev users systemd-journal input bluetooth netdev i2c gpio admin spi iio
> docker tisdk weston-launch xenomai cloud9ide pwm eqep remoteproc]
> cmdline:[console=ttyS0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4
> rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
> dmesg | grep remote
> [   10.000747] remoteproc remoteproc0: 5882.ipu is available
> [   10.042150] remoteproc remoteproc1: 5502.ipu is available
> [   10.054416] remoteproc remoteproc2: 4080.dsp is available
> [   10.055056] remoteproc remoteproc3: 4100.dsp is available
> [   10.113018] remoteproc remoteproc1: powering up 5502.ipu
> [   10.113037] remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4,
> size 3751356
> [   10.201346] remoteproc remoteproc0: powering up 5882.ipu
> [   10.201367] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4,
> size 7051536
> [   10.234158] remoteproc remoteproc1: registered virtio0 (type 7)
> [   10.234164] remoteproc remoteproc1: remote processor 5502.ipu is
> now up
> [   10.252833] remoteproc remoteproc0: registered virtio1 (type 7)
> [   10.252845] remoteproc remoteproc0: remote processor 5882.ipu is
> now up
> [   10.419761] Modules linked in: omap_remoteproc virtio_rpmsg_bus
> rpmsg_core usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether libcomposite
> uio_pdrv_genirq uio cmemk(O) spidev
> [   10.420732] Modules linked in: omap_remoteproc virtio_rpmsg_bus
> rpmsg_core usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether libcomposite
> uio_pdrv_genirq uio cmemk(O) spidev
> [   10.421741] Modules linked in: omap_remoteproc virtio_rpmsg_bus
> rpmsg_core usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether libcomposite
> uio_pdrv_genirq uio cmemk(O) spidev
> [   10.590953] remoteproc remoteproc2: powering up 4080.dsp
> [   10.590972] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66,
> size 21014532
> [   10.649036] 

Re: [beagleboard] PRU 2 0 memory addresses

['Mark Lazarewicz' via BeagleBoard]

Please rephrase the question 
You said you used AM5729 addresses on BBC and BIG this will confuse people.
You also said you find this below in code. It's possible that's an offset only 
#define RCOUT_PRUSS_RAM_BASE      0x4b28

Stick what's in the reference manual and then verify that with any code 
accessing area you need as a cross check
Find the offset in manual cross check software offsets is my suggestion 
Mark 


Sent from Yahoo Mail on Android 
 
  On Sun, Jan 3, 2021 at 9:47 PM, Vinicius 
Juvinski wrote:   Hi guys,
today to load the a code to PRU on BBB, BBG and Pocket we are using this 
addresses:
POCKET:#define RCIN_PRUSS_RAM_BASE   0x4a301000#define RCOUT_PRUSS_RAM_BASE 
0x4a30#define RCOUT_PRUSS_CTRL_BASE 0x4a322000#define RCOUT_PRUSS_IRAM_BASE 
0x4a334000
BBB:#define RCIN_PRUSS_RAM_BASE   0x4a303000#define RCOUT_PRUSS_RAM_BASE 
0x4a302000#define RCOUT_PRUSS_CTRL_BASE 0x4a324000#define RCOUT_PRUSS_IRAM_BASE 
0x4a338000
Anyone please help me in what is the addresses for PRU2_0 for this addresses ? 
I tried all the addresses I found at AM5729 Reference manual and digging the 
filesystem I achived this addresses:#define RCOUT_PRUSS_RAM_BASE      
0x4b28#define RCOUT_PRUSS_CTRL_BASE     0x4b24000#define 
RCOUT_PRUSS_IRAM_BASE     0x4b2b4000#define RCIN_PRUSS_RAM_BASE       0x4b281000
But or the beagle freeze or there are sigbus error. I create a custom dtb and 
all pins are as expected.
Thanks for your help


This is the version script:
root@beaglebone:~/ardupilot# 
/opt/scripts/tools/version.shgit:/opt/scripts/:[fa783d879c7ae9986f2d97977a8f8987bb16f72e]model:[BeagleBoard.org_BeagleBone_AI]dogtag:[BeagleBoard.org
 Debian Buster IoT TIDL Image 
2020-11-30]bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
2020.10-rc1-1-gc5bc0aaa70 (Aug 24 2020 - 16:42:42 -0500)]:[location: dd 
MBR]bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
2020.10-rc1-1-gc5bc0aaa70 (Aug 24 2020 - 16:42:42 -0500)]:[location: dd 
MBR]kernel:[4.14.108-ti-r137]nodejs:[v10.21.0]device-tree-override:[dtb=am572x-juva1.dtb]/boot/uEnv.txt
 Settings:pkg check: to individually upgrade run: [sudo apt install 
--only-upgrade 
]pkg:[bb-cape-overlays]:[4.14.20201221.0-0~buster+20201221]pkg:[bb-customizations]:[1.20201105.0-0~buster+20201110]pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]pkg:[kmod]:[26-1]pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]groups:[debian
 : debian adm kmem dialout cdrom floppy audio dip video plugdev users 
systemd-journal input bluetooth netdev i2c gpio admin spi iio docker tisdk 
weston-launch xenomai cloud9ide pwm eqep 
remoteproc]cmdline:[console=ttyS0,115200n8 root=/dev/mmcblk0p1 ro 
rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 
rng_core.default_quality=100 quiet]dmesg | grep remote[   10.000747] remoteproc 
remoteproc0: 5882.ipu is available[   10.042150] remoteproc remoteproc1: 
5502.ipu is available[   10.054416] remoteproc remoteproc2: 4080.dsp is 
available[   10.055056] remoteproc remoteproc3: 4100.dsp is available[   
10.113018] remoteproc remoteproc1: powering up 5502.ipu[   10.113037] 
remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3751356[   
10.201346] remoteproc remoteproc0: powering up 5882.ipu[   10.201367] 
remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 7051536[   
10.234158] remoteproc remoteproc1: registered virtio0 (type 7)[   10.234164] 
remoteproc remoteproc1: remote processor 5502.ipu is now up[   10.252833] 
remoteproc remoteproc0: registered virtio1 (type 7)[   10.252845] remoteproc 
remoteproc0: remote processor 5882.ipu is now up[   10.419761] Modules 
linked in: omap_remoteproc virtio_rpmsg_bus rpmsg_core usb_f_ncm 
usb_f_mass_storage usb_f_rndis u_ether libcomposite uio_pdrv_genirq uio 
cmemk(O) spidev[   10.420732] Modules linked in: omap_remoteproc 
virtio_rpmsg_bus rpmsg_core usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether 
libcomposite uio_pdrv_genirq uio cmemk(O) spidev[   10.421741] Modules linked 
in: omap_remoteproc virtio_rpmsg_bus rpmsg_core usb_f_ncm usb_f_mass_storage 
usb_f_rndis u_ether libcomposite uio_pdrv_genirq uio cmemk(O) spidev[   
10.590953] remoteproc remoteproc2: powering up 4080.dsp[   10.590972] 
remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 21014532[   
10.649036] remoteproc remoteproc2: registered virtio2 (type 7)[   10.649050] 
remoteproc remoteproc2: remote processor 4080.dsp is now up[   10.758789] 
remoteproc remoteproc3: powering up 4100.dsp[   10.758812] remoteproc 
remoteproc3: Booting fw image dra7-dsp2-fw.xe66, size 21014532[   10.800268] 
remoteproc remoteproc3: registered virtio3 (type 7)[   10.800276] remoteproc 
remoteproc3: remote processor 4100.dsp is now up[   16.681661] remoteproc 
remoteproc4: 4b234000.pru is available[   16.688795] remoteproc 

[beagleboard] PRU 2 0 memory addresses

[Vinicius Juvinski]

Hi guys,

today to load the a code to PRU on BBB, BBG and Pocket we are using this 
addresses:

POCKET:
#define RCIN_PRUSS_RAM_BASE   0x4a301000
#define RCOUT_PRUSS_RAM_BASE 0x4a30
#define RCOUT_PRUSS_CTRL_BASE 0x4a322000
#define RCOUT_PRUSS_IRAM_BASE 0x4a334000

BBB:
#define RCIN_PRUSS_RAM_BASE   0x4a303000
#define RCOUT_PRUSS_RAM_BASE 0x4a302000
#define RCOUT_PRUSS_CTRL_BASE 0x4a324000
#define RCOUT_PRUSS_IRAM_BASE 0x4a338000

Anyone please help me in what is the addresses for PRU2_0 for this 
addresses ? I tried all the addresses I found at AM5729 Reference manual 
and digging the filesystem I achived this addresses:
#define RCOUT_PRUSS_RAM_BASE  0x4b28
#define RCOUT_PRUSS_CTRL_BASE 0x4b24000
#define RCOUT_PRUSS_IRAM_BASE 0x4b2b4000
#define RCIN_PRUSS_RAM_BASE   0x4b281000

But or the beagle freeze or there are sigbus error. I create a custom dtb 
and all pins are as expected.

Thanks for your help



This is the version script:

root@beaglebone:~/ardupilot# /opt/scripts/tools/version.sh
git:/opt/scripts/:[fa783d879c7ae9986f2d97977a8f8987bb16f72e]
model:[BeagleBoard.org_BeagleBone_AI]
dogtag:[BeagleBoard.org Debian Buster IoT TIDL Image 2020-11-30]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
2020.10-rc1-1-gc5bc0aaa70 (Aug 24 2020 - 16:42:42 -0500)]:[location: dd 
MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
2020.10-rc1-1-gc5bc0aaa70 (Aug 24 2020 - 16:42:42 -0500)]:[location: dd 
MBR]
kernel:[4.14.108-ti-r137]
nodejs:[v10.21.0]
device-tree-override:[dtb=am572x-juva1.dtb]
/boot/uEnv.txt Settings:
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20201221.0-0~buster+20201221]
pkg:[bb-customizations]:[1.20201105.0-0~buster+20201110]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal input bluetooth netdev i2c gpio admin spi iio 
docker tisdk weston-launch xenomai cloud9ide pwm eqep remoteproc]
cmdline:[console=ttyS0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   10.000747] remoteproc remoteproc0: 5882.ipu is available
[   10.042150] remoteproc remoteproc1: 5502.ipu is available
[   10.054416] remoteproc remoteproc2: 4080.dsp is available
[   10.055056] remoteproc remoteproc3: 4100.dsp is available
[   10.113018] remoteproc remoteproc1: powering up 5502.ipu
[   10.113037] remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4, 
size 3751356
[   10.201346] remoteproc remoteproc0: powering up 5882.ipu
[   10.201367] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, 
size 7051536
[   10.234158] remoteproc remoteproc1: registered virtio0 (type 7)
[   10.234164] remoteproc remoteproc1: remote processor 5502.ipu is now 
up
[   10.252833] remoteproc remoteproc0: registered virtio1 (type 7)
[   10.252845] remoteproc remoteproc0: remote processor 5882.ipu is now 
up
[   10.419761] Modules linked in: omap_remoteproc virtio_rpmsg_bus 
rpmsg_core usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether libcomposite 
uio_pdrv_genirq uio cmemk(O) spidev
[   10.420732] Modules linked in: omap_remoteproc virtio_rpmsg_bus 
rpmsg_core usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether libcomposite 
uio_pdrv_genirq uio cmemk(O) spidev
[   10.421741] Modules linked in: omap_remoteproc virtio_rpmsg_bus 
rpmsg_core usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether libcomposite 
uio_pdrv_genirq uio cmemk(O) spidev
[   10.590953] remoteproc remoteproc2: powering up 4080.dsp
[   10.590972] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, 
size 21014532
[   10.649036] remoteproc remoteproc2: registered virtio2 (type 7)
[   10.649050] remoteproc remoteproc2: remote processor 4080.dsp is now 
up
[   10.758789] remoteproc remoteproc3: powering up 4100.dsp
[   10.758812] remoteproc remoteproc3: Booting fw image dra7-dsp2-fw.xe66, 
size 21014532
[   10.800268] remoteproc remoteproc3: registered virtio3 (type 7)
[   10.800276] remoteproc remoteproc3: remote processor 4100.dsp is now 
up
[   16.681661] remoteproc remoteproc4: 4b234000.pru is available
[   16.688795] remoteproc remoteproc5: 4b238000.pru is available
[   16.690645] remoteproc remoteproc6: 4b2b4000.pru is available
[   16.693835] remoteproc remoteproc7: 4b2b8000.pru is available
dmesg | grep pru
[   16.498643] pruss 4b20.pruss: creating PRU cores and other child 
platform devices
[   16.550295] pruss 4b28.pruss: creating PRU cores and other child 
platform devices
[   16.681661] remoteproc remoteproc4: 4b234000.pru is available
[   16.681730] pru-rproc 4b234000.pru: PRU rproc node 

[beagleboard] PRU - I2C on BBAI (WAS: PRU - ADC on BBAI

[Dennis Lee Bieber]

On Tue, 20 Oct 2020 05:33:26 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"pierric...-jemvhsqn...@public.gmane.org"
 wrote:

>Hi Denis, 
>Thanks for the help and sorry that I only answer now.
>I understand what you mean with the I2C, I tried to change the topic of the 
>post without luck yet. I am starting to work on that with the examples you

Well, hopefully you find this post then, as it should have new subject
line.
 
>have provided. Do you think that the PRUDAQ project (here 
>) can also be a good 
>starting point it seems that he is doing bit-banging on the /src/pru0.p and 
>/src/pru1.p codes? 

Not quite... The PRUDAQ AD9201 is a parallel I/O module. See
https://github.com/google/prudaq/wiki/InputOutput

PRU0 is bit-banged to generate the sampling rate clock and that is all
it does, while PRU1 is used to read 10 data (GPIO lines) in parallel for
each sample, and then transfers that sample via shared RAM to the ARM
processor. ALL 10 bits of the sample value are available on each clock
cycle (it appears the first channel on clock HIGH, and second channel on
clock LOW). The chip you are using transfers samples in I2C serial format
so you have to combine the bits into bytes/words before making them
available to whatever processor is going to use them, AND you have to
provide the overhead control data too (the I2C address/command bytes).

>Finally, I will have a beginner's question about bit-banging: I have read 
>that bit-banging is much slower that using an i2c library, but as far as I 
>understand an i2c library is doing the same as bit-banging or am I missing 
>something huge here ? 

There is I2C hardware in the chip itself (block diagram, page three of
TI SPRS953F; specifications page 269)[page 5716/section 24.1 of the TRM,
SPRUHZ6L]. Just as with UARTs, the kernel passes full bytes (or even more)
to the I2C hardware, and the hardware (essentially a shift register)
handles the serial I/O, only signaling the kernel when it is ready for more
data (or has received data to give to the kernel). The kernel/ARM-processor
is not tied up monitoring status pins and looping over the bits in the data
manipulating I/O pins.

To have the PRU control the I2C modules would likely require disabling
them in the ARM kernel (device tree) and, as I recall implying months ago,
writing a "driver" that runs on the PRU which would write to the specific
I2C module control registers (section 24.1.6 of the TRM lists those).


-- 
Dennis L Bieber

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/lpstoftghnj8c2566mtoqciv15j5cojfuf%404ax.com.

[beagleboard] PRU Memory Store Instruction with Autoincrement?

[Andrew P. Lentvorski]

Hi, folks,

I'm trying to dump R31 over and over into either RAM0 or Shared DRAM (Data 
RAM).

So, basically it looks like I have to do:

Store R31 to address in register
Increment address in register
(Lather rinse repeat)

As that stands, that's a 100MHz sample of R31.  Is there anyway to do the 
autoincrement on the store?  That would double my sampling rate to 200MHz 
which would be the maximum possible.

Alternatively, is there a different way to sample and store R31 repeatedly 
to RAM0 or Shared DRAM?  I can't seem to see one, but there are so many 
permutation of Store Burst, mapping, the broadside transfer bus, and 
peripherals that I can quite easily be missing something that someone more 
experienced knows about.

Thanks.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f6018682-11cb-4370-a7ed-8cab21011d4dn%40googlegroups.com.

[beagleboard] PRU - ADC on BBAI

[Pierrick Rauby]

Hi All, 
I am trying to implement deterministic data acquisition on the Beaglebone 
AI.
I was thinking of using the PRU with the ADC as it is done on one the 
TechLab example analogIn.pru0.c 
,
 
however, as the BBAI is not based on the AM335x chip the STMPE811QTR ADC 
needs to be interfaced with the PRU through I2C and I am not quite sure how 
to achieve that. I have checked Mark Yoder's PRU cookbook without luck and 
I do not find any PRU example specific to the ADC on the Beaglebone AI. I 
would like to know where I can find example of the use of I2C bus with the 
PRU and the configuration of the ADC of the Beaglebone AI.
Thanks,
Pierrick 

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7f781529-207c-456e-97e6-7bf00286e7dco%40googlegroups.com.

[beagleboard] PRU interrupt program

[t . n . jayasudhaa]

Hello,

I am trying to configure a low latency interrupt to detect change in GPIO 
input pin i.e. input to Beagle Bone AI changes from 0 ->1 or 1-> 0 , it 
should generate an interrupt. I want to do this preferably in PRU by 
implementing an ISR .

Do you have an example code?

Regards,
Jayasudhaa

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1174f1eb-d35d-42d0-b02a-2d7cf39b5ba9o%40googlegroups.com.

[beagleboard] PRU IEP timers non-responsive

[Fred Frey]

Hello

I'm trying to write a simple program to test the IEP timers. Ideally I'd 
like to be able to poll the timer and get an unsigned long value back, but 
for this test, I followed what I read in this post:

https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/08/12/beaglebone-pru-timer-functionality

With a few minor changes -- I provide a different GPIO pin, made it loop 
forever, and made the frequency for the square wave ~2kHz.

I also have a different way of configuring the IEP/INTC. I manually defined 
the addresses:

#define IEP_HOME((volatile unsigned long*)0x2E000)
#define TMR_GLOBAL_CFG (*(IEP_HOME+0x00))
#define TMR_GLOBAL_STATUS   (*(IEP_HOME+0x04))
#define TMR_COMPEN (*(IEP_HOME+0x08))
#define TMR_COUNT(*(IEP_HOME+0x0C))
#define TMR_CMP0   (*(IEP_HOME+0x48))
#define TMR_CMP_STATUS (*(IEP_HOME+0x44))
#define TMR_CMP_CFG   (*(IEP_HOME+0x40))

...

#define INTC_HOME   ((volatile unsigned long*)(0x2))

#define INTC_SECR0  (*(INTC_HOME+0x280))
#define INTC_SECR1  (*(INTC_HOME+0x284))


And I configured them like so:

TMR_GLOBAL_CFG &= 0xfffe; // disable timer

TMR_COUNT = 0x0; // reset timer

TMR_CMP_STATUS = 0xff; // clear compare status

TMR_CMP0 = 10; // 0.0025 SEC @ 200 MHz

TMR_COMPEN &= 0xff00;  // set compensation to 0

TMR_CMP_CFG &= 0x03; // enable cmp0 and reset on event

INTC_SECR0 = 0x;
INTC_SECR1 = 0x;

TMR_GLOBAL_CFG = 0x11; // enable counter


When I read from TMR_COUNT, it's always 0, and the interrupt never fires. 
What am I missing?

Thanks,
Fred

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f0094b81-8d47-4631-91c5-b9f93e2888a5o%40googlegroups.com.

[beagleboard] PRU pins on BBAI

[Mark A. Yoder]

I see that the SRM[1] ([2] is easier to read) for the BBAI shows that some 
PRU pins appear at 2 of the P8/P9 header pins.

Is this really so?

--Mark

[1] 
https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#pru-icss2-pin-access
[2] 
https://docs.google.com/spreadsheets/d/1dFSBVem86vAUD7MLXvqdS-N0Efi8_g_O1iTqzql8DAo/edit#gid=0

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2d54785c-148b-45e6-9475-7b5d23861e10o%40googlegroups.com.

Re: [beagleboard] PRU Beginner Questions (2)

[V37E00E]

Many thanks for your reply and a friendly hat tip for all your efforts with
Beaglebone.org - it is appreciated!

I was thinking that maybe GPREG30 := 0xd233c9c3 represents some debugging
info but couldn't figure out what was setting it.

for the default PRU firmware => yes it makes sense to have some basic REPL
using rpmsg for hacking / validation PRU_RPMsg_Echo_Interrupt0
/ PRU_RPMsg_Echo_Interrupt1 might be a candidate. ???

I'm not up to Git just yet so I'm not much help.

Once again thank you kindly for your reply and work.

On Sun, May 10, 2020 at 1:13 PM Jason Kridner  wrote:

>
>
> On May 10, 2020, at 4:09 AM, V37E00E  wrote:
>
> 
>
> Hello,
>
>
> I’m a beginner learning about PRU with a couple of questions.  I’ve been
> using as reference:
>
>- PRU Cookbook (thank you Mark)
>- Exploring BeagleBone by Derek Molloy
>- TI Examples & Labs
>https://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>
> *Questions:*
>
> 1.   1.  Default firmware for PRU0/1:
>
> root@beaglebone:~# cat /sys/class/remoteproc/remoteproc*/firmware
>
> am335x-pm-firmware.elf
>
> am335x-pru0-fw
>
> am335x-pru1-fw
>
>
>
> root@beaglebone:~# find / -name am335x-pru?-fw
>
> /lib/firmware/am335x-pru0-fw
>
> /lib/firmware/am335x-pru1-fw
>
>
>
> What do these programs do?  I haven’t found any source code to explain
> what is inside.  I think the files come from TI (compiled form), but what
> happens if I
>
> echo start > state for the default firmware?  Seems strange to have this
> as the default with no clues about what is inside.
>
>
> There’s no defacto pru firmware. Robert and I discussed loading a firmware
> image that puts the processor in a hold loop just to have something in
> there by default. I imagine that is what this is.
>
>
>
> 2.   What is the source for the __R30 pin configurations (default?.
> Fresh boot =>
>
>
> Check https://github.com/beagleboard/customizations. This is where Robert
> and I discussed putting it.
>
> root@beaglebone:~# cat /sys/kernel/debug/remoteproc/remoteproc1/regs |
> grep "GPREG30 "
>
> GPREG30 := 0xd233c9c3CT_REG30 := 0x4000
>
>
>
> I’ve looked in:
>
> U-Boot, am335x-boneblack-uboot, cape_universal,
> AM335X-PRU-RPROC-4-14-TI-00A0 and googled around but can’t find anything
> that looks like it sets __R30 at boot.
>
>
> With a LED connected to P9-27, P9-28, P9-29:
>
> config-pin P9-27 pruout => LED is low
>
> config-pin P9-28 pruout => LED is high
>
> config-pin P9-28 pruout => LED is high
>
> For me, it seems strange that some pins would be high by "default".  What
> is setting these values as high???
>
>
>
> Many thanks in advance for any clues.
>
>
> There was nothing done to my knowledge to make these known or specific. I
> suggest you provide a firmware load if you want them to be specific.
>
> Patches welcome.
>
> There are some thoughts to load the PRUs with a small REPL through rpmsg
> for quick hacking.
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/3f51b584-e0bc-4474-9710-5a96f53d5177%40googlegroups.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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/150EE7B5-2D68-4623-82E2-3180F12F0201%40gmail.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAETrxsWmy2cGUyRXr2c%3DwjCH6_EUu2-wZy58TetkWZxzyV31gA%40mail.gmail.com.

Re: [beagleboard] PRU Beginner Questions (2)

[Jason Kridner]

> On May 10, 2020, at 4:09 AM, V37E00E  wrote:
> 
> 
> Hello,
> 
> 
> 
> I’m a beginner learning about PRU with a couple of questions.  I’ve been 
> using as reference:
> 
> PRU Cookbook (thank you Mark)
> Exploring BeagleBone by Derek Molloy
> TI Examples & Labs 
> https://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
> Questions:
> 
> 1.   1.  Default firmware for PRU0/1:
> 
> root@beaglebone:~# cat /sys/class/remoteproc/remoteproc*/firmware
> 
> am335x-pm-firmware.elf
> 
> am335x-pru0-fw
> 
> am335x-pru1-fw
> 
>  
> 
> root@beaglebone:~# find / -name am335x-pru?-fw
> 
> /lib/firmware/am335x-pru0-fw
> 
> /lib/firmware/am335x-pru1-fw
> 
>  
> 
> What do these programs do?  I haven’t found any source code to explain what 
> is inside.  I think the files come from TI (compiled form), but what happens 
> if I
> 
> echo start > state for the default firmware?  Seems strange to have this as 
> the default with no clues about what is inside.
> 

There’s no defacto pru firmware. Robert and I discussed loading a firmware 
image that puts the processor in a hold loop just to have something in there by 
default. I imagine that is what this is. 

>  
> 
> 2.   What is the source for the __R30 pin configurations (default?.  
> Fresh boot =>
> 

Check https://github.com/beagleboard/customizations. This is where Robert and I 
discussed putting it. 

> root@beaglebone:~# cat /sys/kernel/debug/remoteproc/remoteproc1/regs | grep 
> "GPREG30 "
> 
> GPREG30 := 0xd233c9c3CT_REG30 := 0x4000
> 
>  
> 
> I’ve looked in:
> 
> U-Boot, am335x-boneblack-uboot, cape_universal, AM335X-PRU-RPROC-4-14-TI-00A0 
> and googled around but can’t find anything that looks like it sets __R30 at 
> boot.  
> 
> 
> 
> With a LED connected to P9-27, P9-28, P9-29:
> 
> config-pin P9-27 pruout => LED is low
> 
> config-pin P9-28 pruout => LED is high
> 
> config-pin P9-28 pruout => LED is high
> 
> For me, it seems strange that some pins would be high by "default".  What is 
> setting these values as high??? 
> 
>  
> 
> Many thanks in advance for any clues.
> 

There was nothing done to my knowledge to make these known or specific. I 
suggest you provide a firmware load if you want them to be specific. 

Patches welcome. 

There are some thoughts to load the PRUs with a small REPL through rpmsg for 
quick hacking. 

> -- 
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/3f51b584-e0bc-4474-9710-5a96f53d5177%40googlegroups.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/150EE7B5-2D68-4623-82E2-3180F12F0201%40gmail.com.

[beagleboard] PRU Beginner Questions (2)

[V37E00E]

Hello,


I’m a beginner learning about PRU with a couple of questions.  I’ve been 
using as reference:

   - PRU Cookbook (thank you Mark) 
   - Exploring BeagleBone by Derek Molloy 
   - TI Examples & Labs 
   https://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs

*Questions:*

1.   1.  Default firmware for PRU0/1:

root@beaglebone:~# cat /sys/class/remoteproc/remoteproc*/firmware

am335x-pm-firmware.elf

am335x-pru0-fw

am335x-pru1-fw

 

root@beaglebone:~# find / -name am335x-pru?-fw

/lib/firmware/am335x-pru0-fw

/lib/firmware/am335x-pru1-fw

 

What do these programs do?  I haven’t found any source code to explain what 
is inside.  I think the files come from TI (compiled form), but what 
happens if I 

echo start > state for the default firmware?  Seems strange to have this as 
the default with no clues about what is inside.

 

2.   What is the source for the __R30 pin configurations (default?.  
Fresh boot => 

root@beaglebone:~# cat /sys/kernel/debug/remoteproc/remoteproc1/regs | grep 
"GPREG30 "

GPREG30 := 0xd233c9c3CT_REG30 := 0x4000

 

I’ve looked in: 

U-Boot, am335x-boneblack-uboot, cape_universal, 
AM335X-PRU-RPROC-4-14-TI-00A0 and googled around but can’t find anything 
that looks like it sets __R30 at boot.  


With a LED connected to P9-27, P9-28, P9-29:

config-pin P9-27 pruout => LED is low

config-pin P9-28 pruout => LED is high

config-pin P9-28 pruout => LED is high

For me, it seems strange that some pins would be high by "default".  What 
is setting these values as high???  

 

Many thanks in advance for any clues.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3f51b584-e0bc-4474-9710-5a96f53d5177%40googlegroups.com.

Re: [beagleboard] PRU locking up Beaglebone AI

[Jason Kridner]

Got a more complete answer from the TI support team:

This is seems classic. The Remote Core, PRU in this case, is trying to
access GPIO bank shared with Linux.

Linux, by default owns all GPIO banks and if there are no GPIO lines
requested by Linux - the GPIO bank will be powered down.

Correct solution:
- GPIOs used by the Remote core has to be grouped in some GPIO bank X and
that bank has to be removed from Linux
   (DT - disabled or even completely removed).
   Remote core can use this GPIO bank X (including GPIO IRQ), but need
ensure it's enabled.

Possible option:
  - some line from GPIO bank X are used by Linux and some by Remote core
!! but not as IRQ sources !!
  IF:
  (a) GPIOX_Y is used by some Linux driver and requested before Remote core
loaded
  (b) unused GPIOX_Z line can be requested through sysfs/gpio_ioctl
interface before Remote core loaded
  Remote core can access GPIOX_A, but only through GPIO_SETDATAOUT,
GPIO_CLEARDATAOUT, GPIO_DATAIN

*not supported*
- Linux and remote Core FW can't share GPIO bank if both want to use GPIO
IRQs.

On Wed, Apr 29, 2020 at 5:01 PM John Allwine  wrote:

> This makes a whole lot more sense now, because I swear I had it working on
> those GPIO ports at one point. I think I had exported pins manually while
> testing things. Thanks for the help!
>
> On Wed, Apr 29, 2020 at 2:59 PM John Allwine  wrote:
>
>> That did it! I exported pin 8.43:
>>
>> echo 226 > /sys/class/gpio/export
>>
>> And now the PRUs can write to the set and clear addresses for GPIO8.
>>
>> I also exported 8.26:
>>
>> echo 124 > /sys/class/gpio/export
>>
>> And now the PRUs can write to the set and clear addresses for GPIO4.
>>
>> On Wed, Apr 29, 2020 at 11:42 AM Jason Kridner 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
>>> char...@steinkuehler.net> wrote:
>>>
 Regarding your bus errors, I don't see anything in the TRM that
 indicates the PRU shouldn't be able to talk to all of the GPIO banks.

 I have, however, seen bus errors on uninitialized GPIO banks which come
 up disabled by default.  Check to make sure at least one GPIO pin is
 exported by the Linux Kernel (either manually or via device tree) and
 see if the bus errors go away.

>>>
>>> I'll double-down on that feedback. I forwarded this to the team at TI
>>> and they said it is likely that the GPIO bank doesn't have its clock
>>> enabled. I inquired what the minimal action to enable the clock would be,
>>> but haven't heard back yet. Enabling one of the GPIOs in the bank in Linux
>>> seems like a sure way to do it.
>>>
>>> I'll get back when I can find anything more minimal than that.
>>>
>>>


 On 4/28/2020 4:45 PM, John Allwine wrote:
 > Using that test, I was able to quickly check to see which GPIO ports
 I was
 > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2
 doesn't have
 > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and
 7 that
 > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
 GPIO 4
 > and 8 can all be mapped to direct outputs on certain PRUs. I'll need
 to
 > document how each pin can be used, but it seems like just about all
 the P8
 > and P9 pins can be used as long as you know which PRU to run it on for
 > direct outputs and which are suitable to be used as GPIO outputs.
 >
 > On Tue, Apr 28, 2020 at 1:59 PM John Allwine >>> >
 > wrote:
 >
 >> Ok, I have a more localized test that triggers the exception:
 >>
 >>
 https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
 >>
 >> Two stack traces can be seen in dmesg after running that on the PRU.
 If it
 >> has something to do with the device tree, this is the overlay I'm
 using:
 >>
 >>
 https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
 >>
 >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine 
 wrote:
 >>
 >>> Are there any ramifications of the PRU writing 0 to both the set and
 >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the
 device tree
 >>> has several overlapping pins allocated to being direct outputs on
 the PRU?
 >>> The issue seems to arise when I write to those two addresses on the
 PRU, as
 >>> well as the set and clear addresses of GPIO4 (0x48059190 and
 0x48059194).
 >>> What could cause that to trigger an exception in the kernel?
 >>>
 >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
 wrote:
 >>>
  It seems that even if I hardcode the addresses in there (to
 eliminate
  the possibility that my registers were getting overwritten
 somewhere), that
  I get the bus error.  Does enabling the OCP Master port work the
 same way
  as on the BBB? It's 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

This makes a whole lot more sense now, because I swear I had it working on
those GPIO ports at one point. I think I had exported pins manually while
testing things. Thanks for the help!

On Wed, Apr 29, 2020 at 2:59 PM John Allwine  wrote:

> That did it! I exported pin 8.43:
>
> echo 226 > /sys/class/gpio/export
>
> And now the PRUs can write to the set and clear addresses for GPIO8.
>
> I also exported 8.26:
>
> echo 124 > /sys/class/gpio/export
>
> And now the PRUs can write to the set and clear addresses for GPIO4.
>
> On Wed, Apr 29, 2020 at 11:42 AM Jason Kridner 
> wrote:
>
>>
>>
>> On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
>> char...@steinkuehler.net> wrote:
>>
>>> Regarding your bus errors, I don't see anything in the TRM that
>>> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>>>
>>> I have, however, seen bus errors on uninitialized GPIO banks which come
>>> up disabled by default.  Check to make sure at least one GPIO pin is
>>> exported by the Linux Kernel (either manually or via device tree) and
>>> see if the bus errors go away.
>>>
>>
>> I'll double-down on that feedback. I forwarded this to the team at TI and
>> they said it is likely that the GPIO bank doesn't have its clock enabled. I
>> inquired what the minimal action to enable the clock would be, but haven't
>> heard back yet. Enabling one of the GPIOs in the bank in Linux seems like a
>> sure way to do it.
>>
>> I'll get back when I can find anything more minimal than that.
>>
>>
>>>
>>>
>>> On 4/28/2020 4:45 PM, John Allwine wrote:
>>> > Using that test, I was able to quickly check to see which GPIO ports I
>>> was
>>> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't
>>> have
>>> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7
>>> that
>>> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
>>> GPIO 4
>>> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
>>> > document how each pin can be used, but it seems like just about all
>>> the P8
>>> > and P9 pins can be used as long as you know which PRU to run it on for
>>> > direct outputs and which are suitable to be used as GPIO outputs.
>>> >
>>> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
>>> > wrote:
>>> >
>>> >> Ok, I have a more localized test that triggers the exception:
>>> >>
>>> >>
>>> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
>>> >>
>>> >> Two stack traces can be seen in dmesg after running that on the PRU.
>>> If it
>>> >> has something to do with the device tree, this is the overlay I'm
>>> using:
>>> >>
>>> >>
>>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>>> >>
>>> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine 
>>> wrote:
>>> >>
>>> >>> Are there any ramifications of the PRU writing 0 to both the set and
>>> >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the
>>> device tree
>>> >>> has several overlapping pins allocated to being direct outputs on
>>> the PRU?
>>> >>> The issue seems to arise when I write to those two addresses on the
>>> PRU, as
>>> >>> well as the set and clear addresses of GPIO4 (0x48059190 and
>>> 0x48059194).
>>> >>> What could cause that to trigger an exception in the kernel?
>>> >>>
>>> >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
>>> wrote:
>>> >>>
>>>  It seems that even if I hardcode the addresses in there (to
>>> eliminate
>>>  the possibility that my registers were getting overwritten
>>> somewhere), that
>>>  I get the bus error.  Does enabling the OCP Master port work the
>>> same way
>>>  as on the BBB? It's supposedly being set here:
>>> 
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
>>> 
>>>  On Tue, Apr 28, 2020 at 11:47 AM John Allwine 
>>> wrote:
>>> 
>>> > It's the hal_pru_generic code. It definitely smells like a bus
>>> error.
>>> > In fact, if I comment out the lines that write to the GPIO, it
>>> stops
>>> > happening, so it seems like I have the wrong addresses in there,
>>> but I'm
>>> > struggling figuring out how that could be.
>>> >
>>> > These lines are where the GPIO ports are written to in memory:
>>> >
>>> >
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
>>> >
>>> > Theoretically, the addresses should be set to the clear addresses
>>> of
>>> > GPIO3, GPIO5, GPIO6 and GPIO7:
>>> >
>>> > Addresses defined here:
>>> >
>>> >
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
>>> >
>>> > Loaded into registers here:
>>> >
>>> >
>>> 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

That did it! I exported pin 8.43:

echo 226 > /sys/class/gpio/export

And now the PRUs can write to the set and clear addresses for GPIO8.

I also exported 8.26:

echo 124 > /sys/class/gpio/export

And now the PRUs can write to the set and clear addresses for GPIO4.

On Wed, Apr 29, 2020 at 11:42 AM Jason Kridner 
wrote:

>
>
> On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> Regarding your bus errors, I don't see anything in the TRM that
>> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>>
>> I have, however, seen bus errors on uninitialized GPIO banks which come
>> up disabled by default.  Check to make sure at least one GPIO pin is
>> exported by the Linux Kernel (either manually or via device tree) and
>> see if the bus errors go away.
>>
>
> I'll double-down on that feedback. I forwarded this to the team at TI and
> they said it is likely that the GPIO bank doesn't have its clock enabled. I
> inquired what the minimal action to enable the clock would be, but haven't
> heard back yet. Enabling one of the GPIOs in the bank in Linux seems like a
> sure way to do it.
>
> I'll get back when I can find anything more minimal than that.
>
>
>>
>>
>> On 4/28/2020 4:45 PM, John Allwine wrote:
>> > Using that test, I was able to quickly check to see which GPIO ports I
>> was
>> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't
>> have
>> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7
>> that
>> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
>> GPIO 4
>> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
>> > document how each pin can be used, but it seems like just about all the
>> P8
>> > and P9 pins can be used as long as you know which PRU to run it on for
>> > direct outputs and which are suitable to be used as GPIO outputs.
>> >
>> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
>> > wrote:
>> >
>> >> Ok, I have a more localized test that triggers the exception:
>> >>
>> >>
>> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
>> >>
>> >> Two stack traces can be seen in dmesg after running that on the PRU.
>> If it
>> >> has something to do with the device tree, this is the overlay I'm
>> using:
>> >>
>> >>
>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>> >>
>> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine 
>> wrote:
>> >>
>> >>> Are there any ramifications of the PRU writing 0 to both the set and
>> >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device
>> tree
>> >>> has several overlapping pins allocated to being direct outputs on the
>> PRU?
>> >>> The issue seems to arise when I write to those two addresses on the
>> PRU, as
>> >>> well as the set and clear addresses of GPIO4 (0x48059190 and
>> 0x48059194).
>> >>> What could cause that to trigger an exception in the kernel?
>> >>>
>> >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
>> wrote:
>> >>>
>>  It seems that even if I hardcode the addresses in there (to eliminate
>>  the possibility that my registers were getting overwritten
>> somewhere), that
>>  I get the bus error.  Does enabling the OCP Master port work the
>> same way
>>  as on the BBB? It's supposedly being set here:
>> 
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
>> 
>>  On Tue, Apr 28, 2020 at 11:47 AM John Allwine 
>> wrote:
>> 
>> > It's the hal_pru_generic code. It definitely smells like a bus
>> error.
>> > In fact, if I comment out the lines that write to the GPIO, it stops
>> > happening, so it seems like I have the wrong addresses in there,
>> but I'm
>> > struggling figuring out how that could be.
>> >
>> > These lines are where the GPIO ports are written to in memory:
>> >
>> >
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
>> >
>> > Theoretically, the addresses should be set to the clear addresses of
>> > GPIO3, GPIO5, GPIO6 and GPIO7:
>> >
>> > Addresses defined here:
>> >
>> >
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
>> >
>> > Loaded into registers here:
>> >
>> >
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
>> > jkrid...@beagleboard.org> wrote:
>> >
>> >> What is the code running on PRUSS2 PRU1?
>> >>
>> >> This line 

Re: [beagleboard] PRU locking up Beaglebone AI

[Jason Kridner]

On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> Regarding your bus errors, I don't see anything in the TRM that
> indicates the PRU shouldn't be able to talk to all of the GPIO banks.
>
> I have, however, seen bus errors on uninitialized GPIO banks which come
> up disabled by default.  Check to make sure at least one GPIO pin is
> exported by the Linux Kernel (either manually or via device tree) and
> see if the bus errors go away.
>

I'll double-down on that feedback. I forwarded this to the team at TI and
they said it is likely that the GPIO bank doesn't have its clock enabled. I
inquired what the minimal action to enable the clock would be, but haven't
heard back yet. Enabling one of the GPIOs in the bank in Linux seems like a
sure way to do it.

I'll get back when I can find anything more minimal than that.


>
>
> On 4/28/2020 4:45 PM, John Allwine wrote:
> > Using that test, I was able to quickly check to see which GPIO ports I
> was
> > able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't
> have
> > any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7
> that
> > I can use for hal_pru_generic. The P8 and P9 pins that are mapped to
> GPIO 4
> > and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
> > document how each pin can be used, but it seems like just about all the
> P8
> > and P9 pins can be used as long as you know which PRU to run it on for
> > direct outputs and which are suitable to be used as GPIO outputs.
> >
> > On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
> > wrote:
> >
> >> Ok, I have a more localized test that triggers the exception:
> >>
> >>
> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
> >>
> >> Two stack traces can be seen in dmesg after running that on the PRU. If
> it
> >> has something to do with the device tree, this is the overlay I'm using:
> >>
> >>
> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
> >>
> >> On Tue, Apr 28, 2020 at 1:20 PM John Allwine  wrote:
> >>
> >>> Are there any ramifications of the PRU writing 0 to both the set and
> >>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device
> tree
> >>> has several overlapping pins allocated to being direct outputs on the
> PRU?
> >>> The issue seems to arise when I write to those two addresses on the
> PRU, as
> >>> well as the set and clear addresses of GPIO4 (0x48059190 and
> 0x48059194).
> >>> What could cause that to trigger an exception in the kernel?
> >>>
> >>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine 
> wrote:
> >>>
>  It seems that even if I hardcode the addresses in there (to eliminate
>  the possibility that my registers were getting overwritten
> somewhere), that
>  I get the bus error.  Does enabling the OCP Master port work the same
> way
>  as on the BBB? It's supposedly being set here:
> 
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
> 
>  On Tue, Apr 28, 2020 at 11:47 AM John Allwine 
> wrote:
> 
> > It's the hal_pru_generic code. It definitely smells like a bus error.
> > In fact, if I comment out the lines that write to the GPIO, it stops
> > happening, so it seems like I have the wrong addresses in there, but
> I'm
> > struggling figuring out how that could be.
> >
> > These lines are where the GPIO ports are written to in memory:
> >
> >
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
> >
> > Theoretically, the addresses should be set to the clear addresses of
> > GPIO3, GPIO5, GPIO6 and GPIO7:
> >
> > Addresses defined here:
> >
> >
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
> >
> > Loaded into registers here:
> >
> >
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
> > jkrid...@beagleboard.org> wrote:
> >
> >> What is the code running on PRUSS2 PRU1?
> >>
> >> This line kinda spells out an illegal access by that PRU or of that
> >> PRU:
> >> MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in
> Supervisor
> >> mode during Functional access
> >>
> >> Looks like the error is from here:
> >>
> https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135
> >>
> >> Looks like a bus exception to me.
> >>
> >> On Tue, Apr 28, 2020 at 

Re: [beagleboard] PRU locking up Beaglebone AI

[Charles Steinkuehler]

Regarding your bus errors, I don't see anything in the TRM that 
indicates the PRU shouldn't be able to talk to all of the GPIO banks.


I have, however, seen bus errors on uninitialized GPIO banks which come 
up disabled by default.  Check to make sure at least one GPIO pin is 
exported by the Linux Kernel (either manually or via device tree) and 
see if the bus errors go away.



On 4/28/2020 4:45 PM, John Allwine wrote:

Using that test, I was able to quickly check to see which GPIO ports I was
able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't have
any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7 that
I can use for hal_pru_generic. The P8 and P9 pins that are mapped to GPIO 4
and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
document how each pin can be used, but it seems like just about all the P8
and P9 pins can be used as long as you know which PRU to run it on for
direct outputs and which are suitable to be used as GPIO outputs.

On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
wrote:


Ok, I have a more localized test that triggers the exception:

https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c

Two stack traces can be seen in dmesg after running that on the PRU. If it
has something to do with the device tree, this is the overlay I'm using:

https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts

On Tue, Apr 28, 2020 at 1:20 PM John Allwine  wrote:


Are there any ramifications of the PRU writing 0 to both the set and
clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device tree
has several overlapping pins allocated to being direct outputs on the PRU?
The issue seems to arise when I write to those two addresses on the PRU, as
well as the set and clear addresses of GPIO4 (0x48059190 and 0x48059194).
What could cause that to trigger an exception in the kernel?

On Tue, Apr 28, 2020 at 12:19 PM John Allwine  wrote:


It seems that even if I hardcode the addresses in there (to eliminate
the possibility that my registers were getting overwritten somewhere), that
I get the bus error.  Does enabling the OCP Master port work the same way
as on the BBB? It's supposedly being set here:
https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176

On Tue, Apr 28, 2020 at 11:47 AM John Allwine  wrote:


It's the hal_pru_generic code. It definitely smells like a bus error.
In fact, if I comment out the lines that write to the GPIO, it stops
happening, so it seems like I have the wrong addresses in there, but I'm
struggling figuring out how that could be.

These lines are where the GPIO ports are written to in memory:

https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217

Theoretically, the addresses should be set to the clear addresses of
GPIO3, GPIO5, GPIO6 and GPIO7:

Addresses defined here:

https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307

Loaded into registers here:

https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264







On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
jkrid...@beagleboard.org> wrote:


What is the code running on PRUSS2 PRU1?

This line kinda spells out an illegal access by that PRU or of that
PRU:
MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor
mode during Functional access

Looks like the error is from here:
https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135

Looks like a bus exception to me.

On Tue, Apr 28, 2020 at 11:46 AM  wrote:


I'm getting this stack trace in dmesg, but I'm unsure what it means
or how to figure out what it means. As far as I can tell, the code running
on the PRU is working. I'm generating a 100Khz signal on a direct output,
and am able to successfully measure this signal. The Beaglebone is locking
up, though, and I believe this stack trace is being spammed so heavily that
the logging is taking over the CPU and my ssh shell gets locked out.

I'm using this device tree overlay:
https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts

The code I'm running is implemented in PRU Assembly that is assembled
with pasm. pasm outputs a .bin file and I need a .elf file for running it
with remoteproc, so I'm jumping through some hoops to do that conversion.
The elf file does seem to work, but I'm not sure if I need to do more to
ensure I'm specifying what resources I need access to or something like
that. I can go into more detail if need be.

The stack trace is below. Any ideas about 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

Using that test, I was able to quickly check to see which GPIO ports I was
able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't have
any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7 that
I can use for hal_pru_generic. The P8 and P9 pins that are mapped to GPIO 4
and 8 can all be mapped to direct outputs on certain PRUs. I'll need to
document how each pin can be used, but it seems like just about all the P8
and P9 pins can be used as long as you know which PRU to run it on for
direct outputs and which are suitable to be used as GPIO outputs.

On Tue, Apr 28, 2020 at 1:59 PM John Allwine 
wrote:

> Ok, I have a more localized test that triggers the exception:
>
> https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c
>
> Two stack traces can be seen in dmesg after running that on the PRU. If it
> has something to do with the device tree, this is the overlay I'm using:
>
> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>
> On Tue, Apr 28, 2020 at 1:20 PM John Allwine  wrote:
>
>> Are there any ramifications of the PRU writing 0 to both the set and
>> clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device tree
>> has several overlapping pins allocated to being direct outputs on the PRU?
>> The issue seems to arise when I write to those two addresses on the PRU, as
>> well as the set and clear addresses of GPIO4 (0x48059190 and 0x48059194).
>> What could cause that to trigger an exception in the kernel?
>>
>> On Tue, Apr 28, 2020 at 12:19 PM John Allwine  wrote:
>>
>>> It seems that even if I hardcode the addresses in there (to eliminate
>>> the possibility that my registers were getting overwritten somewhere), that
>>> I get the bus error.  Does enabling the OCP Master port work the same way
>>> as on the BBB? It's supposedly being set here:
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
>>>
>>> On Tue, Apr 28, 2020 at 11:47 AM John Allwine  wrote:
>>>
 It's the hal_pru_generic code. It definitely smells like a bus error.
 In fact, if I comment out the lines that write to the GPIO, it stops
 happening, so it seems like I have the wrong addresses in there, but I'm
 struggling figuring out how that could be.

 These lines are where the GPIO ports are written to in memory:

 https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217

 Theoretically, the addresses should be set to the clear addresses of
 GPIO3, GPIO5, GPIO6 and GPIO7:

 Addresses defined here:

 https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307

 Loaded into registers here:

 https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264







 On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner <
 jkrid...@beagleboard.org> wrote:

> What is the code running on PRUSS2 PRU1?
>
> This line kinda spells out an illegal access by that PRU or of that
> PRU:
> MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor
> mode during Functional access
>
> Looks like the error is from here:
> https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135
>
> Looks like a bus exception to me.
>
> On Tue, Apr 28, 2020 at 11:46 AM  wrote:
>
>> I'm getting this stack trace in dmesg, but I'm unsure what it means
>> or how to figure out what it means. As far as I can tell, the code 
>> running
>> on the PRU is working. I'm generating a 100Khz signal on a direct output,
>> and am able to successfully measure this signal. The Beaglebone is 
>> locking
>> up, though, and I believe this stack trace is being spammed so heavily 
>> that
>> the logging is taking over the CPU and my ssh shell gets locked out.
>>
>> I'm using this device tree overlay:
>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>>
>> The code I'm running is implemented in PRU Assembly that is assembled
>> with pasm. pasm outputs a .bin file and I need a .elf file for running it
>> with remoteproc, so I'm jumping through some hoops to do that conversion.
>> The elf file does seem to work, but I'm not sure if I need to do more to
>> ensure I'm specifying what resources I need access to or something like
>> that. I can go into more detail if need be.
>>
>> The stack trace is below. Any ideas about what 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

Ok, I have a more localized test that triggers the exception:
https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c

Two stack traces can be seen in dmesg after running that on the PRU. If it
has something to do with the device tree, this is the overlay I'm using:
https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts

On Tue, Apr 28, 2020 at 1:20 PM John Allwine  wrote:

> Are there any ramifications of the PRU writing 0 to both the set and clear
> addresses of GPIO8 (0x48053190 and 0x48053194), when the device tree has
> several overlapping pins allocated to being direct outputs on the PRU? The
> issue seems to arise when I write to those two addresses on the PRU, as
> well as the set and clear addresses of GPIO4 (0x48059190 and 0x48059194).
> What could cause that to trigger an exception in the kernel?
>
> On Tue, Apr 28, 2020 at 12:19 PM John Allwine  wrote:
>
>> It seems that even if I hardcode the addresses in there (to eliminate the
>> possibility that my registers were getting overwritten somewhere), that I
>> get the bus error.  Does enabling the OCP Master port work the same way as
>> on the BBB? It's supposedly being set here:
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
>>
>> On Tue, Apr 28, 2020 at 11:47 AM John Allwine  wrote:
>>
>>> It's the hal_pru_generic code. It definitely smells like a bus error. In
>>> fact, if I comment out the lines that write to the GPIO, it stops
>>> happening, so it seems like I have the wrong addresses in there, but I'm
>>> struggling figuring out how that could be.
>>>
>>> These lines are where the GPIO ports are written to in memory:
>>>
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
>>>
>>> Theoretically, the addresses should be set to the clear addresses of
>>> GPIO3, GPIO5, GPIO6 and GPIO7:
>>>
>>> Addresses defined here:
>>>
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
>>>
>>> Loaded into registers here:
>>>
>>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
>>> wrote:
>>>
 What is the code running on PRUSS2 PRU1?

 This line kinda spells out an illegal access by that PRU or of that PRU:
 MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor
 mode during Functional access

 Looks like the error is from here:
 https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135

 Looks like a bus exception to me.

 On Tue, Apr 28, 2020 at 11:46 AM  wrote:

> I'm getting this stack trace in dmesg, but I'm unsure what it means or
> how to figure out what it means. As far as I can tell, the code running on
> the PRU is working. I'm generating a 100Khz signal on a direct output, and
> am able to successfully measure this signal. The Beaglebone is locking up,
> though, and I believe this stack trace is being spammed so heavily that 
> the
> logging is taking over the CPU and my ssh shell gets locked out.
>
> I'm using this device tree overlay:
> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>
> The code I'm running is implemented in PRU Assembly that is assembled
> with pasm. pasm outputs a .bin file and I need a .elf file for running it
> with remoteproc, so I'm jumping through some hoops to do that conversion.
> The elf file does seem to work, but I'm not sure if I need to do more to
> ensure I'm specifying what resources I need access to or something like
> that. I can go into more detail if need be.
>
> The stack trace is below. Any ideas about what is going on are
> appreciated!
>
> [  168.153783] [ cut here ]
> [  168.153829] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147
> l3_interrupt_handler+0x27c/0x39c
> [  168.153851] 4400.ocp:L3 Custom Error: MASTER PRUSS2 PRU1 TARGET
> L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
> [  168.153865] Modules linked in: xt_conntrack ipt_MASQUERADE
> nf_nat_masquerade_ipv4 rpmsg_rpc rpmsg_proto bnep btsdio bluetooth
> ecdh_generic brcmfmac pvrsrvkm(O) brcmutil cfg80211 uio_pruss_shmem evdev
> joydev stmpe_adc omap_remoteproc virtio_rpmsg_bus rpmsg_core 8021q garp 
> mrp
> stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> usb_f_acm nf_conntrack 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

Are there any ramifications of the PRU writing 0 to both the set and clear
addresses of GPIO8 (0x48053190 and 0x48053194), when the device tree has
several overlapping pins allocated to being direct outputs on the PRU? The
issue seems to arise when I write to those two addresses on the PRU, as
well as the set and clear addresses of GPIO4 (0x48059190 and 0x48059194).
What could cause that to trigger an exception in the kernel?

On Tue, Apr 28, 2020 at 12:19 PM John Allwine  wrote:

> It seems that even if I hardcode the addresses in there (to eliminate the
> possibility that my registers were getting overwritten somewhere), that I
> get the bus error.  Does enabling the OCP Master port work the same way as
> on the BBB? It's supposedly being set here:
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176
>
> On Tue, Apr 28, 2020 at 11:47 AM John Allwine  wrote:
>
>> It's the hal_pru_generic code. It definitely smells like a bus error. In
>> fact, if I comment out the lines that write to the GPIO, it stops
>> happening, so it seems like I have the wrong addresses in there, but I'm
>> struggling figuring out how that could be.
>>
>> These lines are where the GPIO ports are written to in memory:
>>
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
>>
>> Theoretically, the addresses should be set to the clear addresses of
>> GPIO3, GPIO5, GPIO6 and GPIO7:
>>
>> Addresses defined here:
>>
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
>>
>> Loaded into registers here:
>>
>> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
>> wrote:
>>
>>> What is the code running on PRUSS2 PRU1?
>>>
>>> This line kinda spells out an illegal access by that PRU or of that PRU:
>>> MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor
>>> mode during Functional access
>>>
>>> Looks like the error is from here:
>>> https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135
>>>
>>> Looks like a bus exception to me.
>>>
>>> On Tue, Apr 28, 2020 at 11:46 AM  wrote:
>>>
 I'm getting this stack trace in dmesg, but I'm unsure what it means or
 how to figure out what it means. As far as I can tell, the code running on
 the PRU is working. I'm generating a 100Khz signal on a direct output, and
 am able to successfully measure this signal. The Beaglebone is locking up,
 though, and I believe this stack trace is being spammed so heavily that the
 logging is taking over the CPU and my ssh shell gets locked out.

 I'm using this device tree overlay:
 https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts

 The code I'm running is implemented in PRU Assembly that is assembled
 with pasm. pasm outputs a .bin file and I need a .elf file for running it
 with remoteproc, so I'm jumping through some hoops to do that conversion.
 The elf file does seem to work, but I'm not sure if I need to do more to
 ensure I'm specifying what resources I need access to or something like
 that. I can go into more detail if need be.

 The stack trace is below. Any ideas about what is going on are
 appreciated!

 [  168.153783] [ cut here ]
 [  168.153829] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147
 l3_interrupt_handler+0x27c/0x39c
 [  168.153851] 4400.ocp:L3 Custom Error: MASTER PRUSS2 PRU1 TARGET
 L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
 [  168.153865] Modules linked in: xt_conntrack ipt_MASQUERADE
 nf_nat_masquerade_ipv4 rpmsg_rpc rpmsg_proto bnep btsdio bluetooth
 ecdh_generic brcmfmac pvrsrvkm(O) brcmutil cfg80211 uio_pruss_shmem evdev
 joydev stmpe_adc omap_remoteproc virtio_rpmsg_bus rpmsg_core 8021q garp mrp
 stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
 usb_f_acm nf_conntrack u_serial usb_f_ecm usb_f_mass_storage iptable_mangle
 iptable_filter usb_f_rndis u_ether libcomposite cmemk(O) uio_pdrv_genirq
 uio spidev pruss_soc_bus pru_rproc pruss pruss_intc ip_tables x_tables
 [  168.154474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW  O
 4.14.108-ti-r119 #1
 [  168.154490] Hardware name: Generic DRA74X (Flattened Device Tree)
 [  168.154538] [] (unwind_backtrace) from []
 (show_stack+0x20/0x24)
 [  168.154575] [] (show_stack) from []
 (dump_stack+0x80/0x94)
 [  168.154609] [] (dump_stack) from []
 (__warn+0xf8/0x110)
 [  

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

It seems that even if I hardcode the addresses in there (to eliminate the
possibility that my registers were getting overwritten somewhere), that I
get the bus error.  Does enabling the OCP Master port work the same way as
on the BBB? It's supposedly being set here:
https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L174-L176

On Tue, Apr 28, 2020 at 11:47 AM John Allwine  wrote:

> It's the hal_pru_generic code. It definitely smells like a bus error. In
> fact, if I comment out the lines that write to the GPIO, it stops
> happening, so it seems like I have the wrong addresses in there, but I'm
> struggling figuring out how that could be.
>
> These lines are where the GPIO ports are written to in memory:
>
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217
>
> Theoretically, the addresses should be set to the clear addresses of
> GPIO3, GPIO5, GPIO6 and GPIO7:
>
> Addresses defined here:
>
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307
>
> Loaded into registers here:
>
> https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264
>
>
>
>
>
>
>
> On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
> wrote:
>
>> What is the code running on PRUSS2 PRU1?
>>
>> This line kinda spells out an illegal access by that PRU or of that PRU:
>> MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor
>> mode during Functional access
>>
>> Looks like the error is from here:
>> https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135
>>
>> Looks like a bus exception to me.
>>
>> On Tue, Apr 28, 2020 at 11:46 AM  wrote:
>>
>>> I'm getting this stack trace in dmesg, but I'm unsure what it means or
>>> how to figure out what it means. As far as I can tell, the code running on
>>> the PRU is working. I'm generating a 100Khz signal on a direct output, and
>>> am able to successfully measure this signal. The Beaglebone is locking up,
>>> though, and I believe this stack trace is being spammed so heavily that the
>>> logging is taking over the CPU and my ssh shell gets locked out.
>>>
>>> I'm using this device tree overlay:
>>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>>>
>>> The code I'm running is implemented in PRU Assembly that is assembled
>>> with pasm. pasm outputs a .bin file and I need a .elf file for running it
>>> with remoteproc, so I'm jumping through some hoops to do that conversion.
>>> The elf file does seem to work, but I'm not sure if I need to do more to
>>> ensure I'm specifying what resources I need access to or something like
>>> that. I can go into more detail if need be.
>>>
>>> The stack trace is below. Any ideas about what is going on are
>>> appreciated!
>>>
>>> [  168.153783] [ cut here ]
>>> [  168.153829] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147
>>> l3_interrupt_handler+0x27c/0x39c
>>> [  168.153851] 4400.ocp:L3 Custom Error: MASTER PRUSS2 PRU1 TARGET
>>> L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
>>> [  168.153865] Modules linked in: xt_conntrack ipt_MASQUERADE
>>> nf_nat_masquerade_ipv4 rpmsg_rpc rpmsg_proto bnep btsdio bluetooth
>>> ecdh_generic brcmfmac pvrsrvkm(O) brcmutil cfg80211 uio_pruss_shmem evdev
>>> joydev stmpe_adc omap_remoteproc virtio_rpmsg_bus rpmsg_core 8021q garp mrp
>>> stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
>>> usb_f_acm nf_conntrack u_serial usb_f_ecm usb_f_mass_storage iptable_mangle
>>> iptable_filter usb_f_rndis u_ether libcomposite cmemk(O) uio_pdrv_genirq
>>> uio spidev pruss_soc_bus pru_rproc pruss pruss_intc ip_tables x_tables
>>> [  168.154474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW  O
>>> 4.14.108-ti-r119 #1
>>> [  168.154490] Hardware name: Generic DRA74X (Flattened Device Tree)
>>> [  168.154538] [] (unwind_backtrace) from []
>>> (show_stack+0x20/0x24)
>>> [  168.154575] [] (show_stack) from []
>>> (dump_stack+0x80/0x94)
>>> [  168.154609] [] (dump_stack) from []
>>> (__warn+0xf8/0x110)
>>> [  168.154636] [] (__warn) from []
>>> (warn_slowpath_fmt+0x58/0x74)
>>> [  168.154667] [] (warn_slowpath_fmt) from []
>>> (l3_interrupt_handler+0x27c/0x39c)
>>> [  168.154703] [] (l3_interrupt_handler) from []
>>> (__handle_irq_event_percpu+0xbc/0x280)
>>> [  168.154734] [] (__handle_irq_event_percpu) from
>>> [] (handle_irq_event_percpu+0x3c/0x8c)
>>> [  168.154761] [] (handle_irq_event_percpu) from []
>>> (handle_irq_event+0x48/0x6c)
>>> [  168.154792] [] (handle_irq_event) from []
>>> (handle_fasteoi_irq+0xc8/0x17c)
>>> [  168.154822] [] (handle_fasteoi_irq) from []
>>> 

Re: [beagleboard] PRU locking up Beaglebone AI

[John Allwine]

It's the hal_pru_generic code. It definitely smells like a bus error. In
fact, if I comment out the lines that write to the GPIO, it stops
happening, so it seems like I have the wrong addresses in there, but I'm
struggling figuring out how that could be.

These lines are where the GPIO ports are written to in memory:
https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_wait.p#L214-L217

Theoretically, the addresses should be set to the clear addresses of GPIO3,
GPIO5, GPIO6 and GPIO7:

Addresses defined here:
https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/support/pru/pru.h#L303-L307

Loaded into registers here:
https://github.com/PocketNC/machinekit-hal/blob/c8b38386d87abc45baa33593681cbae46d996980/src/hal/drivers/hal_pru_generic/pru_generic.p#L261-L264







On Tue, Apr 28, 2020 at 10:50 AM Jason Kridner 
wrote:

> What is the code running on PRUSS2 PRU1?
>
> This line kinda spells out an illegal access by that PRU or of that PRU:
> MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor
> mode during Functional access
>
> Looks like the error is from here:
> https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135
>
> Looks like a bus exception to me.
>
> On Tue, Apr 28, 2020 at 11:46 AM  wrote:
>
>> I'm getting this stack trace in dmesg, but I'm unsure what it means or
>> how to figure out what it means. As far as I can tell, the code running on
>> the PRU is working. I'm generating a 100Khz signal on a direct output, and
>> am able to successfully measure this signal. The Beaglebone is locking up,
>> though, and I believe this stack trace is being spammed so heavily that the
>> logging is taking over the CPU and my ssh shell gets locked out.
>>
>> I'm using this device tree overlay:
>> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>>
>> The code I'm running is implemented in PRU Assembly that is assembled
>> with pasm. pasm outputs a .bin file and I need a .elf file for running it
>> with remoteproc, so I'm jumping through some hoops to do that conversion.
>> The elf file does seem to work, but I'm not sure if I need to do more to
>> ensure I'm specifying what resources I need access to or something like
>> that. I can go into more detail if need be.
>>
>> The stack trace is below. Any ideas about what is going on are
>> appreciated!
>>
>> [  168.153783] [ cut here ]
>> [  168.153829] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147
>> l3_interrupt_handler+0x27c/0x39c
>> [  168.153851] 4400.ocp:L3 Custom Error: MASTER PRUSS2 PRU1 TARGET
>> L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
>> [  168.153865] Modules linked in: xt_conntrack ipt_MASQUERADE
>> nf_nat_masquerade_ipv4 rpmsg_rpc rpmsg_proto bnep btsdio bluetooth
>> ecdh_generic brcmfmac pvrsrvkm(O) brcmutil cfg80211 uio_pruss_shmem evdev
>> joydev stmpe_adc omap_remoteproc virtio_rpmsg_bus rpmsg_core 8021q garp mrp
>> stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
>> usb_f_acm nf_conntrack u_serial usb_f_ecm usb_f_mass_storage iptable_mangle
>> iptable_filter usb_f_rndis u_ether libcomposite cmemk(O) uio_pdrv_genirq
>> uio spidev pruss_soc_bus pru_rproc pruss pruss_intc ip_tables x_tables
>> [  168.154474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW  O
>> 4.14.108-ti-r119 #1
>> [  168.154490] Hardware name: Generic DRA74X (Flattened Device Tree)
>> [  168.154538] [] (unwind_backtrace) from []
>> (show_stack+0x20/0x24)
>> [  168.154575] [] (show_stack) from []
>> (dump_stack+0x80/0x94)
>> [  168.154609] [] (dump_stack) from []
>> (__warn+0xf8/0x110)
>> [  168.154636] [] (__warn) from []
>> (warn_slowpath_fmt+0x58/0x74)
>> [  168.154667] [] (warn_slowpath_fmt) from []
>> (l3_interrupt_handler+0x27c/0x39c)
>> [  168.154703] [] (l3_interrupt_handler) from []
>> (__handle_irq_event_percpu+0xbc/0x280)
>> [  168.154734] [] (__handle_irq_event_percpu) from []
>> (handle_irq_event_percpu+0x3c/0x8c)
>> [  168.154761] [] (handle_irq_event_percpu) from []
>> (handle_irq_event+0x48/0x6c)
>> [  168.154792] [] (handle_irq_event) from []
>> (handle_fasteoi_irq+0xc8/0x17c)
>> [  168.154822] [] (handle_fasteoi_irq) from []
>> (generic_handle_irq+0x34/0x44)
>> [  168.154850] [] (generic_handle_irq) from []
>> (__handle_domain_irq+0x8c/0xfc)
>> [  168.154879] [] (__handle_domain_irq) from []
>> (gic_handle_irq+0x4c/0x88)
>> [  168.154908] [] (gic_handle_irq) from []
>> (__irq_svc+0x6c/0xa8)
>> [  168.154925] Exception stack(0xc1501ed8 to 0xc1501f20)
>> [  168.154946] 1ec0:
>>  0001 
>> [  168.154973] 1ee0: fe60  c150 c1504e60 c1504dfc
>> c14cbb78 c1501f48 
>> [  168.154997] 1f00:  c1501f34 c1501f14 c1501f28 c012fcb8
>> c0109768 600f0013 
>> [  168.155031] [] 

Re: [beagleboard] PRU locking up Beaglebone AI

[Jason Kridner]

What is the code running on PRUSS2 PRU1?

This line kinda spells out an illegal access by that PRU or of that PRU:
MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode
during Functional access

Looks like the error is from here:
https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/bus/omap_l3_noc.c#L135

Looks like a bus exception to me.

On Tue, Apr 28, 2020 at 11:46 AM  wrote:

> I'm getting this stack trace in dmesg, but I'm unsure what it means or how
> to figure out what it means. As far as I can tell, the code running on the
> PRU is working. I'm generating a 100Khz signal on a direct output, and am
> able to successfully measure this signal. The Beaglebone is locking up,
> though, and I believe this stack trace is being spammed so heavily that the
> logging is taking over the CPU and my ssh shell gets locked out.
>
> I'm using this device tree overlay:
> https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts
>
> The code I'm running is implemented in PRU Assembly that is assembled with
> pasm. pasm outputs a .bin file and I need a .elf file for running it with
> remoteproc, so I'm jumping through some hoops to do that conversion. The
> elf file does seem to work, but I'm not sure if I need to do more to ensure
> I'm specifying what resources I need access to or something like that. I
> can go into more detail if need be.
>
> The stack trace is below. Any ideas about what is going on are appreciated!
>
> [  168.153783] [ cut here ]
> [  168.153829] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147
> l3_interrupt_handler+0x27c/0x39c
> [  168.153851] 4400.ocp:L3 Custom Error: MASTER PRUSS2 PRU1 TARGET
> L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
> [  168.153865] Modules linked in: xt_conntrack ipt_MASQUERADE
> nf_nat_masquerade_ipv4 rpmsg_rpc rpmsg_proto bnep btsdio bluetooth
> ecdh_generic brcmfmac pvrsrvkm(O) brcmutil cfg80211 uio_pruss_shmem evdev
> joydev stmpe_adc omap_remoteproc virtio_rpmsg_bus rpmsg_core 8021q garp mrp
> stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> usb_f_acm nf_conntrack u_serial usb_f_ecm usb_f_mass_storage iptable_mangle
> iptable_filter usb_f_rndis u_ether libcomposite cmemk(O) uio_pdrv_genirq
> uio spidev pruss_soc_bus pru_rproc pruss pruss_intc ip_tables x_tables
> [  168.154474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW  O
> 4.14.108-ti-r119 #1
> [  168.154490] Hardware name: Generic DRA74X (Flattened Device Tree)
> [  168.154538] [] (unwind_backtrace) from []
> (show_stack+0x20/0x24)
> [  168.154575] [] (show_stack) from []
> (dump_stack+0x80/0x94)
> [  168.154609] [] (dump_stack) from []
> (__warn+0xf8/0x110)
> [  168.154636] [] (__warn) from []
> (warn_slowpath_fmt+0x58/0x74)
> [  168.154667] [] (warn_slowpath_fmt) from []
> (l3_interrupt_handler+0x27c/0x39c)
> [  168.154703] [] (l3_interrupt_handler) from []
> (__handle_irq_event_percpu+0xbc/0x280)
> [  168.154734] [] (__handle_irq_event_percpu) from []
> (handle_irq_event_percpu+0x3c/0x8c)
> [  168.154761] [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x48/0x6c)
> [  168.154792] [] (handle_irq_event) from []
> (handle_fasteoi_irq+0xc8/0x17c)
> [  168.154822] [] (handle_fasteoi_irq) from []
> (generic_handle_irq+0x34/0x44)
> [  168.154850] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x8c/0xfc)
> [  168.154879] [] (__handle_domain_irq) from []
> (gic_handle_irq+0x4c/0x88)
> [  168.154908] [] (gic_handle_irq) from []
> (__irq_svc+0x6c/0xa8)
> [  168.154925] Exception stack(0xc1501ed8 to 0xc1501f20)
> [  168.154946] 1ec0:
>  0001 
> [  168.154973] 1ee0: fe60  c150 c1504e60 c1504dfc c14cbb78
> c1501f48 
> [  168.154997] 1f00:  c1501f34 c1501f14 c1501f28 c012fcb8 c0109768
> 600f0013 
> [  168.155031] [] (__irq_svc) from []
> (arch_cpu_idle+0x30/0x4c)
> [  168.155061] [] (arch_cpu_idle) from []
> (default_idle_call+0x30/0x3c)
> [  168.155092] [] (default_idle_call) from []
> (do_idle+0x180/0x214)
> [  168.155124] [] (do_idle) from []
> (cpu_startup_entry+0x28/0x2c)
> [  168.155156] [] (cpu_startup_entry) from []
> (rest_init+0xdc/0xe0)
> [  168.155194] [] (rest_init) from []
> (start_kernel+0x434/0x45c)
> [  168.155217] ---[ end trace d9047b952a20ba7f ]---
>
>
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/fde6b3e0-1a1d-43d5-8f78-14d604a7b1fa%40googlegroups.com
> 

[beagleboard] PRU locking up Beaglebone AI

[john]

I'm getting this stack trace in dmesg, but I'm unsure what it means or how 
to figure out what it means. As far as I can tell, the code running on the 
PRU is working. I'm generating a 100Khz signal on a direct output, and am 
able to successfully measure this signal. The Beaglebone is locking up, 
though, and I believe this stack trace is being spammed so heavily that the 
logging is taking over the CPU and my ssh shell gets locked out. 

I'm using this device tree overlay: 
https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts

The code I'm running is implemented in PRU Assembly that is assembled with 
pasm. pasm outputs a .bin file and I need a .elf file for running it with 
remoteproc, so I'm jumping through some hoops to do that conversion. The 
elf file does seem to work, but I'm not sure if I need to do more to ensure 
I'm specifying what resources I need access to or something like that. I 
can go into more detail if need be.

The stack trace is below. Any ideas about what is going on are appreciated!

[  168.153783] [ cut here ]
[  168.153829] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x27c/0x39c
[  168.153851] 4400.ocp:L3 Custom Error: MASTER PRUSS2 PRU1 TARGET 
L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
[  168.153865] Modules linked in: xt_conntrack ipt_MASQUERADE 
nf_nat_masquerade_ipv4 rpmsg_rpc rpmsg_proto bnep btsdio bluetooth 
ecdh_generic brcmfmac pvrsrvkm(O) brcmutil cfg80211 uio_pruss_shmem evdev 
joydev stmpe_adc omap_remoteproc virtio_rpmsg_bus rpmsg_core 8021q garp mrp 
stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat 
usb_f_acm nf_conntrack u_serial usb_f_ecm usb_f_mass_storage iptable_mangle 
iptable_filter usb_f_rndis u_ether libcomposite cmemk(O) uio_pdrv_genirq 
uio spidev pruss_soc_bus pru_rproc pruss pruss_intc ip_tables x_tables
[  168.154474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW  O
4.14.108-ti-r119 #1
[  168.154490] Hardware name: Generic DRA74X (Flattened Device Tree)
[  168.154538] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[  168.154575] [] (show_stack) from [] 
(dump_stack+0x80/0x94)
[  168.154609] [] (dump_stack) from [] 
(__warn+0xf8/0x110)
[  168.154636] [] (__warn) from [] 
(warn_slowpath_fmt+0x58/0x74)
[  168.154667] [] (warn_slowpath_fmt) from [] 
(l3_interrupt_handler+0x27c/0x39c)
[  168.154703] [] (l3_interrupt_handler) from [] 
(__handle_irq_event_percpu+0xbc/0x280)
[  168.154734] [] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x3c/0x8c)
[  168.154761] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x48/0x6c)
[  168.154792] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xc8/0x17c)
[  168.154822] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x34/0x44)
[  168.154850] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x8c/0xfc)
[  168.154879] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x4c/0x88)
[  168.154908] [] (gic_handle_irq) from [] 
(__irq_svc+0x6c/0xa8)
[  168.154925] Exception stack(0xc1501ed8 to 0xc1501f20)
[  168.154946] 1ec0:  
 0001 
[  168.154973] 1ee0: fe60  c150 c1504e60 c1504dfc c14cbb78 
c1501f48 
[  168.154997] 1f00:  c1501f34 c1501f14 c1501f28 c012fcb8 c0109768 
600f0013 
[  168.155031] [] (__irq_svc) from [] 
(arch_cpu_idle+0x30/0x4c)
[  168.155061] [] (arch_cpu_idle) from [] 
(default_idle_call+0x30/0x3c)
[  168.155092] [] (default_idle_call) from [] 
(do_idle+0x180/0x214)
[  168.155124] [] (do_idle) from [] 
(cpu_startup_entry+0x28/0x2c)
[  168.155156] [] (cpu_startup_entry) from [] 
(rest_init+0xdc/0xe0)
[  168.155194] [] (rest_init) from [] 
(start_kernel+0x434/0x45c)
[  168.155217] ---[ end trace d9047b952a20ba7f ]---



-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fde6b3e0-1a1d-43d5-8f78-14d604a7b1fa%40googlegroups.com.

Re: [beagleboard] PRU example does not work

[Hugo van den Brand]

Could you refer to which version of the image or code repository this
applies?

I have a BBBlack.
Maybe I could try it.

Op wo 8 jan. 2020 15:20 schreef Stephan Böck :

> Hello everybody,
>
> I just got my hands on a BB AI. During my testing I stumbled over an error
> in the Cloud 9 examples.
> I wanted to run the program blinkInternalLED.pru1_1.c of the PRU examples
> of the AI.
>
> The following message appeares in the terminal output if I try to run it
> (note: I work with the cloud 9 IDE):
>
> fatal error: pru_cfg.h: No such file or directory
>  #include 
>
>
> I updated the BB to the latest version. Did I miss something else to be
> able to run the example files? Or is the header for the pru realy missing?
>
>
> Thanks alot
> Stephan
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/dec10490-b3c2-483e-8c30-dc39e81a0a43%40googlegroups.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK0gJ31DFEFFiXkJTW_TQQhPHGUCmEY0jDuK1oj9LFJnys7Uw%40mail.gmail.com.

[beagleboard] PRU example does not work

[Stephan Böck]

Hello everybody,

I just got my hands on a BB AI. During my testing I stumbled over an error 
in the Cloud 9 examples.
I wanted to run the program blinkInternalLED.pru1_1.c of the PRU examples 
of the AI.

The following message appeares in the terminal output if I try to run it 
(note: I work with the cloud 9 IDE): 

fatal error: pru_cfg.h: No such file or directory
 #include 


I updated the BB to the latest version. Did I miss something else to be 
able to run the example files? Or is the header for the pru realy missing?


Thanks alot
Stephan

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dec10490-b3c2-483e-8c30-dc39e81a0a43%40googlegroups.com.

[beagleboard] PRU based Apple IIe videocard

[Tomas Espeleta]

Helllo Guys,
I just wanted to share the first steps of my project: take a look to my 
facebook post:

https://www.facebook.com/groups/5251478676/permalink/10159148656378677/

Best,
Tomas

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6ab46cbf-8d60-46f6-a070-1c1775a5b871%40googlegroups.com.

[beagleboard] PRU phandle is changing

[kaigeissdoerfer via BeagleBoard]

I'm writing a kernel driver that needs to control the PRUs' state using 
rproc_boot(...)/rproc_shutdown(...) 
from linux/remoteproc.h. The functions take a `struct rproc *` as argument. 
I tried using `rproc_get_by_phandle(...)` to get the reference to the PRUs. 
The problem is that the phandles are actually different from one 
installation to the other. E.g. after flashing a fresh image, the PRU 
phandles could be 0xF4 and 0xF5. The next time, after flashing the image, 
the phandles are 0xF6 and 0xF7. They seem, however, to remain the same, if 
I don't flash a new image.

- Why are the phandles different between one image and the other?
- Is there a way to fix them, such that I reliable get pointers to the PRUs 
with `rproc_get_by_phandle()`?
- Is there another, better way to reliably get `struct rproc *`s to the 
PRUs?

Thanks,
Kai

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7a657541-36e4-4efa-95f3-9f59a3b6e4a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Communications: Beaglebone Black

[TJF]

Thanks for quoting the TRM for me (I didn't download the 'c' version yet).

Am Donnerstag, 4. Juli 2019 15:10:38 UTC+2 schrieb Charles Steinkuehler:
>
> On 7/4/2019 2:57 AM, TJF wrote: 
> > Interesting, thanks Charles! 
> > 
> > Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles Steinkuehler: 
> >> 
> >> The 
> >> transfer is terminated if either PRU core stalls for more than 1024 
> >> cycles. 
> > 
> > How to distinguish between a terminated or regular transfer? 
>
> From the TRM: 
> "In direct connect mode (device ID 14), any PRU transaction will be 
> terminated if the stall is greater than 1024 cycles. This will 
> generate the event pr<1/0>_xfr_timeout that is connected to INTC." 
>

So we have to check the event bit and clear it in a second cycle.

My method to HALT one PRU and resume it by the other is less expensive and 
more flexible. It isn't limited to a 1024 cycle window. And by specifying 
any program counter, the halted PRU can continue anywhere, not just at the 
next position in IRAM.

Regards

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a547441e-e653-4000-8885-5c3a936dd1d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Communications: Beaglebone Black

[Charles Steinkuehler]

On 7/4/2019 2:57 AM, TJF wrote:
> Interesting, thanks Charles!
> 
> Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles Steinkuehler:
>>
>> The 
>> transfer is terminated if either PRU core stalls for more than 1024 
>> cycles. 
> 
> How to distinguish between a terminated or regular transfer?

>From the TRM:
"In direct connect mode (device ID 14), any PRU transaction will be
terminated if the stall is greater than 1024 cycles. This will
generate the event pr<1/0>_xfr_timeout that is connected to INTC."

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6e5e75fb-b2a3-a44b-0f2b-a049baf59f7a%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Communications: Beaglebone Black

[TJF]

Interesting, thanks Charles!

Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles Steinkuehler:
>
> The 
> transfer is terminated if either PRU core stalls for more than 1024 
> cycles. 
>

How to distinguish between a terminated or regular transfer?

Regards

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ae6c044c-41ee-449d-8069-9cd8c8481227%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Communications: Beaglebone Black

[Venkatesh Vadde]

Sounds a tad more intricate, but seems powerful. Thanks for letting us
know, Steinkuehler.

On Wed, Jul 3, 2019, 9:05 PM Charles Steinkuehler 
wrote:

> As has been discussed, the PRUs have no direct "interrupt" like
> functionality that interrupts and redirects program execution.
>
> In addition to the various methods already discussed, if you are
> trying to tightly couple program execution between the two PRU cores,
> I suggest using the transfer instructions (XIN/XOUT).  While these
> instructions are typically used to access the scratchpad and hardware
> multiplier, you can also specify a direct connection between the two
> PRU cores.  In this case, one PRU core executes an XIN instruction and
> the other core executes an XOUT.  The core that executes the
> instruction first will stall until the other PRU executes it's
> transfer instruction, at which point the two PRU cores will continue
> executing code, synchronized by the transfer instruction.  The
> transfer is terminated if either PRU core stalls for more than 1024
> cycles.
>
> Details are in the TRM, but you have to have one of the versions with
> full details on the PRU cores (eg: spruh73c or similar).
>
> On 7/2/2019 7:49 AM, Venkatesh Vadde wrote:
> > We are a group working with a Beaglebone and trying to get more time
> > determinism between the PRUs. We are trying to get one PRU to respond to
> a
> > trigger from the other PRU. The INTC framework seems quite complex, and
> we
> > are finding it quite difficult to decipher or understand (but an example
> > might help us build on it). Does the PRU allow for a timed response like
> an
> > interrupt based mechanism? Can someone suggest something for our
> > requirement of communication between the PRUs?
> >
> > Thank you,
> > -Vadde
> >
>
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/30cf3e82-eae4-07cb-7be8-0bf34137de0d%40steinkuehler.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHW0bcxPVtppGTkVd51nkYWgg3J3hvZuJtV1yV%2BhC9TaVhSzWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Communications: Beaglebone Black

[Charles Steinkuehler]

As has been discussed, the PRUs have no direct "interrupt" like
functionality that interrupts and redirects program execution.

In addition to the various methods already discussed, if you are
trying to tightly couple program execution between the two PRU cores,
I suggest using the transfer instructions (XIN/XOUT).  While these
instructions are typically used to access the scratchpad and hardware
multiplier, you can also specify a direct connection between the two
PRU cores.  In this case, one PRU core executes an XIN instruction and
the other core executes an XOUT.  The core that executes the
instruction first will stall until the other PRU executes it's
transfer instruction, at which point the two PRU cores will continue
executing code, synchronized by the transfer instruction.  The
transfer is terminated if either PRU core stalls for more than 1024
cycles.

Details are in the TRM, but you have to have one of the versions with
full details on the PRU cores (eg: spruh73c or similar).

On 7/2/2019 7:49 AM, Venkatesh Vadde wrote:
> We are a group working with a Beaglebone and trying to get more time
> determinism between the PRUs. We are trying to get one PRU to respond to a
> trigger from the other PRU. The INTC framework seems quite complex, and we
> are finding it quite difficult to decipher or understand (but an example
> might help us build on it). Does the PRU allow for a timed response like an
> interrupt based mechanism? Can someone suggest something for our
> requirement of communication between the PRUs?
> 
> Thank you,
> -Vadde
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/30cf3e82-eae4-07cb-7be8-0bf34137de0d%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Communications: Beaglebone Black

[Venkatesh Vadde]

We are a group working with a Beaglebone and trying to get more time
determinism between the PRUs. We are trying to get one PRU to respond to a
trigger from the other PRU. The INTC framework seems quite complex, and we
are finding it quite difficult to decipher or understand (but an example
might help us build on it). Does the PRU allow for a timed response like an
interrupt based mechanism? Can someone suggest something for our
requirement of communication between the PRUs?

Thank you,
-Vadde

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHW0bcwKay6CnG%3DnFKiayk_YHgbOxN4s6_kEoRy8_3Nvu9UqMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU remoteproc[12] not appearing under /sys/class/remoteproc/

[ethshea]

I've just set up a new Debian 9.5 (kernel 14.4.71-ti-r80) image 

 
and made the following changes to /boot/uEnv.txt:

disable_uboot_overlay_video=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo

I've also disabled loading of the uio modules. (
/etc/modprobe.d/pruss-blacklist.conf)
blacklist uio
blacklist uio_pdrv_genirq

However, I don't see any evidence that the rproc module has loaded the PRU:
"uio\|pru"

Specifically, there is no module for the PRU in /sys/class/remoteproc/. 
remoteproc0 appears, but this is for the M3 power management unit.

Am I doing anything wrong? or is there an additional step to allow use of 
the PRUs? What should I look at to debug this issue?

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/175aee21-2342-4047-8de3-e898ff831bf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Remoteproc Carveout Access from Userspace

[Bill M]

Greetings All,

TLDR; what is the best way to access PRU remoteproc carveouts from 
userspace?

I have a (working) project for reading an 8-bit parallel interface camera 
that I originally wrote using UIOPRUSS. I decided to take the plunge and 
work through the remoteproc documentation to see if I could move to that. I 
didn't want to use rpmsg, because I doubted it could handle the data 
velocity (320 x 240 x 24bit color x 15 frames per second = 3,456,000, 
roughly 3MB a second). I discovered carveouts in the resource table 
headers, and thought this was excellent since it was much like how I was 
already doing it with UIOPRUSS. It works and simplifies the code greatly, 
but I have to use debugfs to get the carveout location to mmap to, which 
seems less than ideal. What is the best way to expose the carveout to 
userspace? Any suggestions appreciated.

Thanks!

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4ec3a558-5452-4752-aa26-08f7ae1c927d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Can not change output ...

[gang han]

Can Anyone Help me? my code can not change the output of pru ...



machinekit@beaglebone:~$ uname -a
Linux beaglebone 4.19.26-bone-rt-r26 #1stretch PREEMPT RT Thu Feb 28 
11:27:59 UTC 2019 armv7l GNU/Linux
machinekit@beaglebone:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.19.26-bone-rt-r26
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/.dtbo
#uboot_overlay_addr5=/lib/firmware/.dtbo
#uboot_overlay_addr6=/lib/firmware/.dtbo
#uboot_overlay_addr7=/lib/firmware/.dtbo
###
###Custom Cape
dtb_overlay=/lib/firmware/BBB-CNC-SHENKA-00A0.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.4.x-ti, 4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (6 = 384KB)
#uboot_fdt_buffer=0x6
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e

#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh




DTS:

// Compile with:
// sudo dtc -O dtb -I dts -o /lib/firmware/BBB-CNC-SHENKA-00A0.dtbo -b 0 -@ 
BBB-CNC-SHENKA-00A0.dts  -W no-unit_address_vs_reg

//sudo vim /boot/uEnv.txt
//Custom Cape
//dtb_overlay=/lib/firmware/PRU-GPIO-EXAMPLE-00A0.dtbo
 /dts-v1/;  
 /plugin/;  
 
/ {  
// This determines which boards can use this DTS overlay  
compatible = "ti,beaglebone", "ti,beaglebone-black";  
 
part-number = "BBB-CNC-SHENKA";
version = "00A0";

/*Free up the pins used by the cape from the pinmux helpers.*/
fragment@0 {
target = <>; 
__overlay__ {
P8_07_pinmux { status = "disabled"; };
P8_08_pinmux { status = "disabled"; };
P8_09_pinmux { status = "disabled"; };
P8_10_pinmux { status = "disabled"; };
P8_11_pinmux { status = "disabled"; };
P8_12_pinmux { status = "disabled"; };
P8_13_pinmux { status = "disabled"; };
P8_14_pinmux { status = "disabled"; };
P8_15_pinmux { status = "disabled"; };
P8_16_pinmux { status = "disabled"; };
P8_17_pinmux { status = "disabled"; };
P8_20_pinmux { status = "disabled"; };
P8_21_pinmux { status = "disabled"; };
P8_27_pinmux { status = "disabled"; };
P8_28_pinmux { status = "disabled"; };
P8_29_pinmux { status = "disabled"; };
P8_30_pinmux { status = "disabled"; };
P8_39_pinmux { status = "disabled"; };
P8_40_pinmux { status = "disabled"; };
P8_41_pinmux { status = "disabled"; };
P8_42_pinmux { status = "disabled"; };
P8_43_pinmux { status = "disabled"; };
P8_44_pinmux { status = "disabled"; };
P8_45_pinmux { status = "disabled"; };
P8_46_pinmux { status = "disabled"; };
};
};
fragment@1 {
target = <>;
__overlay__ {
cape-universal { status = "disabled"; };
};
};
fragment@2 {  
target = <_pinmux>;  
__overlay__ {  
cnc_pins: pinmux_cnc_pins {
   pinctrl-single,pins = <  
0x084 0x05 /*P8.20", /* pru1_pru_r30_13 S-DIR pin*/
0x080 0x05 /*P8.21", /* pru1_pru_r30_12   S-Step pin*/
0x0e0 0x05 /*P8.27", /* pru1_pru_r30_8 Spindle-PWM pin*/
0x0e8 0x05 /*P8.28", /* pru1_pru_r30_10 C-DIR pin*/
0x0e4 0x05 /*P8.29", /* pru1_pru_r30_9 C-Step pin*/
0x0b8 0x05 /*P8.39", /* pru1_pru_r30_6 A-DIR pin*/
0x0bc 0x05 /*P8.40", /* pru1_pru_r30_7 A-Step pin*/
0x0b0 0x05 /*P8.41", /* pru1_pru_r30_4 Z-DIR pin*/
0x0b4 0x05 /*P8.42", /* pru1_pru_r30_5 Z-Step pin*/
0x0a8 0x05 /*P8.43", /* pru1_pru_r30_2 Y-DIR pin*/
0x0ac 0x05 /*P8.44", /* pru1_pru_r30_3 Y-Step pin*/
0x0a0 0x05 /*P8.45", /* pru1_pru_r30_0 X-DIR pin*/
0x0a4 0x05 /*P8.46", /* pru1_pru_r30_1 X-Step pin*/ 
0x00c 0x27 /*P8.06", /* gpio1.3 ESTOP pin*/
0x090 0x27 /*P8.07", /* gpio2.2 ESTOP pin*/
0x094 0x27 /*P8.08", /* gpio2.3 X-Limit pin*/
0x09c 0x27 /*P8.09", /* 

[beagleboard] PRU DMA Example

[Anton Nikiforov]

I tried to launch some examples using chain DMA+PRU. I found this git 
repository  https://github.com/maciejjo/beaglebone-pru-dma (There is guide 
i used to launch example: 
https://github.com/maciejjo/beaglebone-pru-dma/tree/master/Documentation) 
But i didn't make it cause of troubles with building new patching kernel. 
Are there some more simply examples with PRU and DMA. And maybe there are 
some more ways to launch examples (without creating module and 
patching/building kernel).

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/056059f5-4d31-4b6d-8013-b5217a65fa11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU does not start.

[gw]

Hello.
I need help regarding PRU.
I tried to enable the PRU by a command below.

*root@beaglebone:/sys/class/remoteproc/remoteproc1# echo 'start' > state
 *
-bash: echo: write error: No such file or directory

But I get above result and PRU does not start.
I also tried sudo sh -c "echo 'start' > state" but I got an I/O error.

Please help me.
Below are related information.


*debian@beaglebone:~$ dmesg |grep pru*
[   82.512558] pruss 4a30.pruss: creating PRU cores and other child 
platform devices
[   82.531307] remoteproc remoteproc1: 4a334000.pru is available
[   82.531436] pru-rproc 4a334000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[   82.539513] remoteproc remoteproc2: 4a338000.pru is available
[   82.539647] pru-rproc 4a338000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a32600
[ 1864.134156] remoteproc remoteproc1: powering up 4a334000.pru
[ 1864.134336] remoteproc remoteproc1: Direct firmware load for 
am335x-pru0-fw failed with error -2

*root@beaglebone:/sys/class/remoteproc/remoteproc1# sudo 
/opt/scripts/tools/version.sh*
git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
eeprom:[A335BNLTBWA51712EW004500]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.71-ti-r80]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[1.115968] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
dmesg | grep gpio-of-helper
[1.127852] gpio-of-helper ocp:cape-universal: ready
END

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e0fb8a2a-07b1-4113-8761-1d0015ac703c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU dev/rpmsg_pru* files don't exist

[Robert Nelson]

On Mon, Feb 25, 2019 at 9:35 AM Lee  wrote:
>
> Hello,
>
> I am trying to send data from the ARM processor to the PRU using rpmsg. After 
> following Greg's guide found here: 
> https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf, I 
> am still unable to see any rpmsg_pru* files in the dev folder. Are there 
> additional instructions for creating the rpmsg_pru* files for newer images 
> and kernels?

TI's broke the userspace interface in every major kernel release,
those directions are for 4.4.12-ti-r31

Re-try with this kernel installed:

sudo /opt/scripts/tools/update_kernel.sh --ti-channel --lts-4_4

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjcfw1TRBbLrN0Msi-m2J0XdFZqFQhNwpju9mWKVAV0eg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU dev/rpmsg_pru* files don't exist

[Lee]

Hello,

I am trying to send data from the ARM processor to the PRU using rpmsg. 
After following Greg's guide found 
here: 
https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf, 
I am still unable to see any rpmsg_pru* files in the dev folder. Are there 
additional instructions for creating the rpmsg_pru* files for newer images 
and kernels?

Debian image: bone-debian-9.5-iot-armhf-2018-10-07-4gb.img

uname -r:  4.14.71-ti-r80

lsmod: 
Module  Size  Used by
8021q  32768  0
garp   16384  1 8021q
mrp20480  1 8021q
stp16384  1 garp
llc16384  2 garp,stp
binfmt_misc20480  1
pru_rproc  28672  0
pruss_soc_bus  16384  0
evdev  24576  1
uio_pdrv_genirq16384  0
uio20480  1 uio_pdrv_genirq
usb_f_mass_storage 53248  2
usb_f_acm  16384  2
u_serial   20480  3 usb_f_acm
usb_f_ecm  20480  2
usb_f_rndis32768  4
u_ether20480  2 usb_f_ecm,usb_f_rndis
libcomposite   65536  18 
usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis
iptable_nat16384  0
nf_conntrack_ipv4  20480  1
nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
nf_nat_ipv416384  1 iptable_nat
nf_nat 32768  1 nf_nat_ipv4
nf_conntrack  143360  3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
iptable_mangle 16384  0
iptable_filter 16384  0
spidev 20480  0
pruss  16384  1 pru_rproc
pruss_intc 16384  1 pru_rproc
ip_tables  24576  3 iptable_mangle,iptable_filter,iptable_nat
x_tables   36864  3 iptable_mangle,ip_tables,iptable_filter

Thanks!

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e50350b7-5f24-4e1d-a046-53bdd457c580%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Cape Demo Starterware not Loading

[Lee]

Hello,

I am following the instructions here: 
http://processors.wiki.ti.com/index.php/PRU_Cape_Getting_Started_Guide
to get started with the BBB PRU Cape Rev 1.2A.

The MLO and app folders are on the SD card, and the serial terminal is 
setup in Putty with all of the required settings. The SD card is inserted 
and the PRU cape and FTDI cable are connected to the BBB. When I open the 
serial terminal and boot the board, I am supposed to see the PRU Cape Demo 
Options, instead, I see the output below. When I type and enter the 
password, nothing happens. What are some possible causes for this error?

Thanks!


U-Boot SPL 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
Trying to boot from MMC2
Loading Environment from EXT4... 
** Unable to use mmc 0:1 for loading the env **

U-Boot 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500), Build: 
jenkins-github_Bootloader-Builder-65

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4... 
** Unable to use mmc 0:1 for loading the env **
Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[000C] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
** Invalid partition 2 **
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
2155 bytes read in 6 ms (350.6 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-4.14.71-ti-r80 ...
10416640 bytes read in 663 ms (15 MiB/s)
debug: [enable_uboot_overlays=1] ...
debug: [enable_uboot_cape_universal=1] ...
debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] ...
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ...
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb ...
loading /boot/dtbs/4.14.71-ti-r80/am335x-boneblack-uboot-univ.dtb ...
161723 bytes read in 26 ms (5.9 MiB/s)
uboot_overlays: [fdt_buffer=0x6] ...
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1440 bytes read in 53 ms (26.4 KiB/s)
uboot_overlays: loading /lib/firmware/BB-HDMI-TDA998x-00A0.dtbo ...
5127 bytes read in 132 ms (37.1 KiB/s)
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
711 bytes read in 115 ms (5.9 KiB/s)
uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo ...
3513 bytes read in 148 ms (22.5 KiB/s)
loading /boot/initrd.img-4.14.71-ti-r80 ...
4739448 bytes read in 305 ms (14.8 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet] ...
debug: [bootz 0x8200 0x8808:485178 8800] ...
## Flattened Device Tree blob at 8800
Booting using the fdt blob at 0x8800
Loading Ramdisk to 8fb7a000, end 8178 ... OK
reserving fdt memory region: addr=8800 size=89000
Loading Device Tree to 8faee000, end 8fb79fff ... OK


Starting kernel ...


[ 0.002101] timer_probe: no matching timers found
[ 1.142680] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 1.442407] omap_voltage_late_init: Voltage driver support not added
[ 1.449790] PM: Cannot get wkup_m3_ipc handle
[ 1.648613] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: no source 
widget found for Playback
[ 1.657622] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: Failed to add 
route Playback -> direct -> TX


Debian GNU/Linux 9 beaglebone ttyS0

BeagleBoard.org Debian Image 2018-10-07

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

Re: [beagleboard] PRU Internal clock

[alanmthomason via BeagleBoard]

Thanks to both of you, this is really helpful.  Charles, this is what I was 
looking for and for this particular problem is what I need, but also thanks 
Bill I will have a look at this timer as well.

On Friday, December 7, 2018 at 7:35:21 PM UTC-5, Charles Steinkuehler wrote:
>
> On 12/7/2018 11:16 AM, alanmthomason via BeagleBoard wrote: 
> > I use the BeagleBone Black PRU for a very time critical task.  I 
> currently 
> > have registers that increment based on how many instructions I have just 
> > run and their type (SBBO's for instance take more than the usual 1 clock 
> > cycle per instruction) so that I can keep track of time.  I have seen 
> > somewhere that you can reset and read an internal clock on the BBB PRUs, 
> > but I just can't seem to find that again.   
> > 
> > Has anyone used this feature, and if so can you guide me on how to go 
> about 
> > reading and resetting? 
>
> There's the Industrial Ethernet Peripheral, mentioned by Bill which 
> includes support for 8 timers. 
>
> In addition, there is an ECAP module within the PRU fabric (separate 
> from the other BBB ECAP timer modules). 
>
> But I think you may be thinking of the Cycle/Stall registers.  You can 
> enable the cycle count register in the Ctrl register (CTR_EN bit), and 
> you can clear the cycle count when the counter is disabled, if desired. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1c969921-303f-4865-bef5-108620b6f67a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Internal clock

[Charles Steinkuehler]

On 12/7/2018 11:16 AM, alanmthomason via BeagleBoard wrote:
> I use the BeagleBone Black PRU for a very time critical task.  I currently 
> have registers that increment based on how many instructions I have just 
> run and their type (SBBO's for instance take more than the usual 1 clock 
> cycle per instruction) so that I can keep track of time.  I have seen 
> somewhere that you can reset and read an internal clock on the BBB PRUs, 
> but I just can't seem to find that again.  
> 
> Has anyone used this feature, and if so can you guide me on how to go about 
> reading and resetting?

There's the Industrial Ethernet Peripheral, mentioned by Bill which
includes support for 8 timers.

In addition, there is an ECAP module within the PRU fabric (separate
from the other BBB ECAP timer modules).

But I think you may be thinking of the Cycle/Stall registers.  You can
enable the cycle count register in the Ctrl register (CTR_EN bit), and
you can clear the cycle count when the counter is disabled, if desired.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/47b45a80-72b1-65a1-6eb1-f6db633c69f6%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Internal clock

[Bill Bitner]

Hi Alan!

There is only 1 of this timer, so expect trouble if you try to use it on
both PRU's at the same time..
That said, the following should do what you want (from Mark Yoder's PRU
Cookbook).   One count == 5ns, so you can do some pretty precise timing.

#include 

# define TEN_US_DELAY  2001
 CT_IEP.TMR_CNT = 0x0; // set the timer to 0
 CT_IEP.TMR_GLB_CFG = 0x11;  / set the timer running and also its
multiplier for a 5ns  per tick.


  while ( CT_IEP.TMR_CNT < TEN_US_DELAY);

Bill Bitner

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOYP4diYApCjY7O2K-UWhnuHXfhyFxqkwZ9rtD-YzVBg5qzTZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Internal clock

[alanmthomason via BeagleBoard]

I use the BeagleBone Black PRU for a very time critical task.  I currently 
have registers that increment based on how many instructions I have just 
run and their type (SBBO's for instance take more than the usual 1 clock 
cycle per instruction) so that I can keep track of time.  I have seen 
somewhere that you can reset and read an internal clock on the BBB PRUs, 
but I just can't seem to find that again.  

Has anyone used this feature, and if so can you guide me on how to go about 
reading and resetting?

Thanks so much, 

Alan

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3462cd99-af77-45ed-b01b-bb605e593e50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU - Can't read data up to 2.5 MHz

[Fred Gomes]

I Gerhard, thank you very much for your answer.

I replaced the "IF" statements by "While", as shown in your example and the
communication got a way faster.  However, I am can't still get data at 10
MHz, I think the problem has to be with writing in the shared memory zone,
I've got the following piece of code:


#define PRU_SHARED_MEM_ADDR 0x0001

   volatile int* buffer = (volatile int *)
PRU_SHARED_MEM_ADDR;
int k = 0;
while((__R31) != cs){ // CS = 0

while((__R31) == sclk){ //sclk = 1

if((__R31) == cs)
goto END;
}
while((__R31) != sclk); //SCLK = 0 --> RISING EDGE
buffer[k/32] = ((__R31) >> miso) << (K%32); --> I lOOSE CLOCKS HERE
k++;
}
END;

Any idea how can I get it a little bit faster? If I remove the MISO reading
line I can catch all the SCK clocks, the problem comes when I add that
line, I think it gets slower because of the access to that memory zone.

Thank you very much,
Fred Gomes

Gerhard Hoffmann  escreveu no dia quarta,
28/11/2018 à(s) 13:42:

>
> Am 28.11.18 um 12:08 schrieb fred.p.gome...@gmail.com:
> ...
>
> state[0] = ((__R31) == sclk) ?  true :  false;
> state[0] = (__R31) == sclk;
>
> should do the same thing, but I would expect the compiler to optimize
> that away. Unrolling the loops and inlining should help, also.
>
> This is how I do the read:
>
> Remember that I read now the SPI data into a CPLD and fetch
> them bytewise.
>
> I switch the 2 byte address lines to the CPLD and then have to wait
> 7 ns for propagation through the CPLD and some time more until
> the ringing at the P8/P9 connector has calmed down. So I must
> wait, say 4 Instructions à 5 nsec before I really get the data.
> That is done with some volatile reads. I had the impression that
> the number of instructions and the delay did not always scale 1:1,
> so it took some pruning with the oscilloscope until I was satisfied.
>
> The canonical solution for your problem is probably to use the
> hardware SPI interface with the PRU, which should work to 48 MBit/s.
> I could not make that work, and in the end I wanted 100 MBit/s anyway.
>
> cheers,
> Gerhard
>
> --
>
>
> // data avail is either (not busy) or (not drl). It is high active.
> // The CPLD takes a little more than 32 Clocks at 100 MHz
> // to get the 32 bits. Then we can read them out, bytewise, and
> // we select the byte using 2 port bits as address.
> // It is probably harmless if that extends slightly into the next
> // conversion since the read activity is decoupled from the ADC core
> // Reading the CPLD does not toggle ADC pins.
> //
> // inline saves 20 nsec of procedure overhead.
>
> inline void wait_data_avail(void){
>
> while  (  __R31 & (1 << DAT_AVAIL)) {};// wait for the high time
> of p9.26 = data_avail
> while  (!(__R31 & (1 << DAT_AVAIL))){};// wait for the low time
> // Now we are at the start of the high time. The ADC transaction
> window opens.
> // next 320 ns we will read the data into the CPLD or program the ADC
> }
>
>
> // read 4 bytes from the CPLD, mask them, shift them & convert to one int.
> // I must read at least 3 times that the results are right ( for address
> setup time)
> // removing a single read makes it 60 nsec faster, 15 nsec per read.
> Should be 5 nsec???
> // reading 3 times takes 40 nsec per bit. That should be enough.
> // reading 4 times takes 60 nsec per bit. Reading __R31 takes abt. 20 ns.
> :-(
> // Von der steigenden Flanke von data_available am P9 bis zum return
> dauert 725 nsec.
> // kill 320 nsec, the time the CPLD needs to fill the shift register
> // Once through the empty loop costs 5 nsec.
> // for( retval=60; retval;  retval--){};
>
> // In the mean time I have changed the CPLD so that it tells when I
> immediately
> // can fetch the data, so I gain 350 nsec that were spent with busy
> waiting previously.
> // Now I should be able to process 3 channels.
> // Using the scope is essential to see where time is lost.
>
> inline int read_adc(void){
>
> int retval;
>
> // Without volatile this runs 3 times as fast, even though __R31 is
> volatile
> // The compiler seems to assume incorrectly that reading __R31 has no
> // side effects. But it has. It spends time and data might change.
> //
> // maybe we could do the merging of the result in the setup time
> // but when the compiler re-arranges instructions that might fail.
>
> volatile unsigned int byte0, byte1, byte2, byte3;
>
> wait_data_avail();
>
> // from here to parking the address at return it takes 350 nsec.
>
> __R30   &= ~(3 << QSEL);// address 0
> byte0= __R31;// address setup time for byte 0
> byte0= __R31;
> //byte0= __R31;
> byte0= __R31;
>
> __R30   |= (1 << QSEL);// address 1
> byte1= __R31;
> byte1= __R31;
> //byte1= __R31;
> byte1= __R31;
>
> __R30   &= ~(3 << QSEL);// address 2,   remove old bit 

[beagleboard] PRU compiler Optimization Issue

[Bill Bitner]

Hi!

First, a *big* thanks to Mark Yoder, who kindly put a whole lot of 
information together to help me figure this out.

I'm attempting to using the BBB to make a simple motor controller and will 
use the PRU's to do the critical timing
events.To demonstrate a baby step, I decided to play around with an 
ultrasonic detector to prove I could generate
timed pulses, and also time an incoming pulse.   I started using Mark's 
PruCookbook set up.   I found that using
the -O 2 flag for clpru, the compiler would *delete* certain looping code.  
 Removing the flag would run the code
properly.   It took a while to figure out what was happening since I'm not 
an expert in assembly, but looking at
the .lst file and using prudebug and single stepping showed me what the 
problem was.

Details:

while (1)
{

runState = pru0Dram[0]; 
if (runState == 0)
{
__R30 &= ~gpio; // Set the GPIO pin to 0, this 
should be a 10 us pulse
continue;
}

onTime  = pru0Dram[1]; 

__R30 |= gpio;
 >>>   while(1)
{
if (counter > onTime)
{
__R30 &= ~gpio; // Set the GPIO pin to 0, this 
should be a 10 us pulse
break;
}
counter += 1;
}

inputState = 0;


without the -O 2 flag, the compiler generates the following assembly code.



259;--
 260;  54 | __R30 |= gpio;  
   

 261;--
 262 007c 00F1002281  LBBO  , r2, 0, 4 ; 
[ALU_PRU] |54| gpio
 263 0080 0012E1FEFE  ORr30, r30, r1  ; 
[ALU_PRU] |54| 
 264.dwpsn  file "pruUltraSonic2.c",line 55,column 
19,is_stmt,isa 0

 265;--
 266;  55 | while(1)
   

 267;--
 268;* 
--*
 269;*   BEGIN LOOP ||$C$L3||
 270;*
 271;*   Loop source line: 55
 272;*   Loop closing brace source line  : 63
 273;*   Known Minimum Trip Count: 1
 274;*   Known Maximum Trip Count: 4294967295
 275;*   Known Max Trip Count Factor : 1
PRU Assembler Unix v2.3.1 Sat Dec  1 17:26:17 2018

Tools Copyright (c) 2012-2017 Texas Instruments Incorporated
/tmp/pru0-gen/pruUltraSonic2.asm PAGE  
  6

 276;* 
--*
 277 0084 ||$C$L3||:
 278.dwpsn  file "pruUltraSonic2.c",line 57,column 
17,is_stmt,isa 0

 279;--
 280;  57 | if (counter > onTime)  


 281;--
 282 0084 00F1142280  LBBO  , r2, 20, 4; 
[ALU_PRU] |57| counter
 283 0088 0058E0EE04  QBLE  ||$C$L4||, r14, r0; 
[ALU_PRU] |57| 
 284;* 
--*
 285.dwpsn  file "pruUltraSonic2.c",line 59,column 
21,is_stmt,isa 0

 286;--
 287;  59 | __R30 &= ~gpio; // Set the GPIO pin to 0, this 
should be a 10 u
 288; | s pulse


 289;--
 290 008c 001600E1E0  NOT   r0, r1; 
[ALU_PRU] |59| 
 291 0090 0010E0FEFE  AND   r30, r30, r0  ; 
[ALU_PRU] |59| 
 292.dwpsn  file "pruUltraSonic2.c",line 60,column 
21,is_stmt,isa 0

 293;--
 294;  60 | break;  
   

 295;--
 296 0094 002100! JMP   ||$C$L5|| ; 
[ALU_PRU] |60| 
 297;* 
--*
 298 0098 ||$C$L4||:
 299.dwpsn  file "pruUltraSonic2.c",line 62,column 
17,is_stmt,isa 0

 300;--
 301;  62 | counter += 1;  

Re: [beagleboard] PRU - Can't read data up to 2.5 MHz

[Gerhard Hoffmann]

Am 28.11.18 um 12:08 schrieb fred.p.gome...@gmail.com:
...

|state[0] = ((__R31) == sclk) ?  true :  false;|
|state[0] = (__R31) == sclk;
|
|
|
|should do the same thing, but I would expect the compiler to optimize|
|that away. Unrolling the loops and inlining should help, also.
|

This is how I do the read:

Remember that I read now the SPI data into a CPLD and fetch
them bytewise.

I switch the 2 byte address lines to the CPLD and then have to wait
7 ns for propagation through the CPLD and some time more until
the ringing at the P8/P9 connector has calmed down. So I must
wait, say 4 Instructions à 5 nsec before I really get the data.
That is done with some volatile reads. I had the impression that
the number of instructions and the delay did not always scale 1:1,
so it took some pruning with the oscilloscope until I was satisfied.

The canonical solution for your problem is probably to use the
hardware SPI interface with the PRU, which should work to 48 MBit/s.
I could not make that work, and in the end I wanted 100 MBit/s anyway.

cheers,
Gerhard

--


// data avail is either (not busy) or (not drl). It is high active.
// The CPLD takes a little more than 32 Clocks at 100 MHz
// to get the 32 bits. Then we can read them out, bytewise, and
// we select the byte using 2 port bits as address.
// It is probably harmless if that extends slightly into the next
// conversion since the read activity is decoupled from the ADC core
// Reading the CPLD does not toggle ADC pins.
//
// inline saves 20 nsec of procedure overhead.

inline void wait_data_avail(void){

    while  (  __R31 & (1 << DAT_AVAIL)) {};    // wait for the high 
time of p9.26 = data_avail

    while  (!(__R31 & (1 << DAT_AVAIL))){};    // wait for the low time
    // Now we are at the start of the high time. The ADC transaction 
window opens.

    // next 320 ns we will read the data into the CPLD or program the ADC
}


// read 4 bytes from the CPLD, mask them, shift them & convert to one int.
// I must read at least 3 times that the results are right ( for address 
setup time)
// removing a single read makes it 60 nsec faster, 15 nsec per read. 
Should be 5 nsec???

// reading 3 times takes 40 nsec per bit. That should be enough.
// reading 4 times takes 60 nsec per bit. Reading __R31 takes abt. 20 
ns. :-(
// Von der steigenden Flanke von data_available am P9 bis zum return 
dauert 725 nsec.

// kill 320 nsec, the time the CPLD needs to fill the shift register
// Once through the empty loop costs 5 nsec.
// for( retval=60; retval;  retval--){};

// In the mean time I have changed the CPLD so that it tells when I 
immediately
// can fetch the data, so I gain 350 nsec that were spent with busy 
waiting previously.

// Now I should be able to process 3 channels.
// Using the scope is essential to see where time is lost.

inline int read_adc(void){

    int retval;

    // Without volatile this runs 3 times as fast, even though __R31 is 
volatile

    // The compiler seems to assume incorrectly that reading __R31 has no
    // side effects. But it has. It spends time and data might change.
    //
    // maybe we could do the merging of the result in the setup time
    // but when the compiler re-arranges instructions that might fail.

    volatile unsigned int byte0, byte1, byte2, byte3;

    wait_data_avail();

    // from here to parking the address at return it takes 350 nsec.

    __R30   &= ~(3 << QSEL);    // address 0
    byte0    = __R31;            // address setup time for byte 0
    byte0    = __R31;
//    byte0    = __R31;
    byte0    = __R31;

    __R30   |= (1 << QSEL);        // address 1
    byte1    = __R31;
    byte1    = __R31;
//    byte1    = __R31;
    byte1    = __R31;

    __R30   &= ~(3 << QSEL);    // address 2,   remove old bit field
    __R30   |=  (2 << QSEL);    // insert new bit field
    byte2   = __R31;
    byte2   = __R31;
//    byte2   = __R31;
    byte2   = __R31;

    __R30   |= (1<< QSEL);        // increment to address 3
    byte3   = __R31;            //
    byte3   = __R31;
//    byte3   = __R31;
    byte3   = __R31;            // get the last byte

    retval  = ((byte0 & 0xff)  )
            | ((byte1 & 0xff) << 8 )
            | ((byte2 & 0xff) << 16)
            | ((byte3 & 0xff) << 24);

    __R30   &= ~(3 << QSEL);    // park address at 0, may be removed.
                                // but makes it easy to spot the action 
on the scope.

    return  retval;
}

--

I have to read data from an SPI master device, which sends the clock 
at 10 MHz. Since the SPI kernel driver only allows to the beagle bone 
to working as SPI Master I had to implement this functionality using a 
PRU.


From what I've read throughout the internet the PRU processing rate is 
200 MHz, so I thought I could easily read data at 10 MHz. Oddly, it 
happens that with transmission rates up to 2.5 MHz I am being unable 

[beagleboard] PRU - Can't read data up to 2.5 MHz

[fred . p . gomes92]

Hello, I need your help 

I have to read data from an SPI master device, which sends the clock at 10 
MHz. Since the SPI kernel driver only allows to the beagle bone to working 
as SPI Master I had to implement this functionality using a PRU.

>From what I've read throughout the internet the PRU processing rate is 200 
MHz, so I thought I could easily read data at 10 MHz. Oddly, it happens 
that with transmission rates up to 2.5 MHz I am being unable to catch all 
the rising edges on the clock pin.

So, here's what I did:

In the PRU0 I wrote the following code:

bool WaitForRisingEdge_sclk(uint32_t sclk)
{ 
state[0] = ((__R31) == sclk) ?  true :  false;
if((state[0] == true) && (previous_state[0] == false))
{
previous_state[0] = state[0];
return true; //Rising edge 
}
else{
previous_state[0] = state[0];
return false;
}
}

void main(void)
{ 
while(1)
{
START:
count_clocks = 0;
while(gpio2[GPIO_DATAIN/4] & P8_8) //Receive notification from the beagle 
bone to read data
{ 

LOOP:
if(WaitForRisingEdge_sclk(sclk)) // wait for rising edge on clock pin
{
//buffer[i] = ((__R31) == miso)?  buffer[i] | 0x01 << k : buffer[i] | 
0x00 << k; 
//buffer[i] =   buffer[i] | 0x01 << k; 
count_clocks++; 
}
else if(WaitForRisingEdge_cs(cs))
{
gpio2[GPIO_SETDATAOUT/4] = P8_7; // Notify the beagle bone that the data 
was already read
buffer[2600] = count_clocks;
goto START;
}
else
{
goto LOOP;
} 
} 
}
}


and I did one simple program ON PRU1 which sends at a certain frequency. I 
got to the conclusion that with transmission rates up to 2.5 MHz and can't 
count all the clocks. I was wondering if there is any better way for 
reading the rising edge, I might be lossoing performance on that function 
itself.

Thank you very much for your help,
-- Fred Gomes



-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0beef84d-177e-4d3a-b877-42728c5891f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU devices taking a very long time to start up

[will]

I have PRU code working great on my BeagleBone Black industrial boards 
using the latest Debian 9.5 2018-10-07 4GB SD IoT flashed to eMMC, but even 
though the board boots up very quickly, I have to wait about *two minutes* 
after boot-up before the PRU cores can be used. Here's the last part of the 
dmesg output showing what I mean:

debian@beaglebone:~$ dmesg | tail -n 22
...
[   41.174241] Mass Storage Function, version: 2009/09/11
[   41.174265] LUN: removable file: (no medium)
[   41.986075] usb0: HOST MAC 44:ea:d8:aa:3e:b5
[   41.987686] usb0: MAC 44:ea:d8:aa:3e:b6
[   42.002600] usb1: HOST MAC 44:ea:d8:aa:3e:b8
[   42.006444] usb1: MAC 44:ea:d8:aa:3e:b9
[   42.254313] configfs-gadget gadget: high-speed config #1: c
[   43.850644] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[  118.823084] pruss 4a30.pruss: creating PRU cores and other child 
platform devices
[  118.859328] remoteproc remoteproc1: 4a334000.pru is available
[  118.859458] pru-rproc 4a334000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[  118.896237] remoteproc remoteproc2: 4a338000.pru is available
[  118.896367] pru-rproc 4a338000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully
[  119.798466] remoteproc remoteproc1: powering up 4a334000.pru
[  119.807907] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 99712
[  119.808701] pruss 4a30.pruss: configured system_events[63-0] = 
0x.0003
[  119.808715] pruss 4a30.pruss: configured intr_channels = 0x0005 
host_intr = 0x0005
[  119.814687] remoteproc remoteproc1: registered virtio0 (type 7)
[  119.814707] remoteproc remoteproc1: remote processor 4a334000.pru is now 
up
[  124.697746] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 
0x1e
[  124.699741] virtio_rpmsg_bus virtio0: rpmsg host is online
[  124.774718] rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: 
/dev/rpmsg_pru30


I didn't snip the output above; there is seriously nothing happening from 
44 seconds to 119 seconds!

I have a bash script to start my PRU program, which is executed by a 
systemd service, but I have to make the shell script wait in a while loop 
for a long time before it is able to echo 'start' to the appropriate link 
location, otherwise I get an error and my PRU program doesn't start up at 
all. This works, but having to wait a couple minutes is ridiculous:

#! /bin/sh
TIMEOUT=1
while [ ! -f /sys/class/remoteproc/remoteproc1/state ]; do
sleep "$TIMEOUT"
done
echo 'start' > /sys/class/remoteproc/remoteproc1/state


Running modprobe -f pru_rproc before the two minutes have passed doesn't 
seem to help.

Has anybody else experienced this? Any idea why it takes so long? Or how I 
would go about debugging this incredibly long delay? Thanks!

-- Will Bain

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/234059b6-2ad9-43d3-8ef4-0bde0142dd25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Pru Reset without BBB reboot?

[true-time]

Many many thanks. prussdrv_pru_reset () make the job.
Two very good tips.
This is going to be a nice day. :-)
All good for you
Peter

Am Mittwoch, 24. Oktober 2018 14:55:39 UTC+2 schrieb Charles Steinkuehler:
>
> On 10/24/2018 5:05 AM, true...@web.de  wrote: 
> > Hello, 
> > 
> > In tests with clpru C programs, the problem arises again and again that 
> the 
> > Pru hangs up. 
> > A simple LED Bink program can then no longer be started. 
> > Is there a way to reset the Pru without rebooting the BBB? 
> > Tips from the network have not worked for me so far. 
> > 
> > thanks to all experts 
>
> It looks like you're using the UIO bindings for the PRU.  If you're 
> also using the prussdrv library, just call the prussdrv_pru_reset() 
> function. 
>
> Otherwise, there's an enable and reset bit in the PRU control register 
> (PRU_ICSS_PRU_CTRL register 0: CTRL bit 0: SOFT_RST_N and bit 1: EN). 
> See the PRU section of the TRM for details. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/03fa9080-4baa-428c-b543-1ef107f6a026%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Pru Reset without BBB reboot?

[Charles Steinkuehler]

On 10/24/2018 5:05 AM, true-t...@web.de wrote:
> Hello,
> 
> In tests with clpru C programs, the problem arises again and again that the 
> Pru hangs up.
> A simple LED Bink program can then no longer be started.
> Is there a way to reset the Pru without rebooting the BBB?
> Tips from the network have not worked for me so far.
> 
> thanks to all experts

It looks like you're using the UIO bindings for the PRU.  If you're
also using the prussdrv library, just call the prussdrv_pru_reset()
function.

Otherwise, there's an enable and reset bit in the PRU control register
(PRU_ICSS_PRU_CTRL register 0: CTRL bit 0: SOFT_RST_N and bit 1: EN).
See the PRU section of the TRM for details.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4a49cf83-7c58-ebbe-96bb-138d446ca909%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Pru Reset without BBB reboot?

[true-time]

Hello,

In tests with clpru C programs, the problem arises again and again that the 
Pru hangs up.
A simple LED Bink program can then no longer be started.
Is there a way to reset the Pru without rebooting the BBB?
Tips from the network have not worked for me so far.

thanks to all experts

Peter

My BBB Setup:

root@beaglebone:/var/lib/cloud9/Packages/ti_cgt_pru_2.3.1# 
/opt/scripts/tools/version.sh
git:/opt/scripts/:[5d0cce48cbd05aafa0d1e7cc1583f5f9a57c199c]
eeprom:[A335BNLT000C1820BBBG0775]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-06-17]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]
kernel:[4.14.53-ti-r62]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20181019.0-0rcnee0~stretch+20181019]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[roboticscape]:[0.4.4-git20180608.0-0rcnee0~stretch+20180609]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : kmem root adm dialout cdrom floppy sudo audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[1.099779] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
dmesg | grep gpio-of-helper
[1.110259] gpio-of-helper ocp:cape-universal: ready
END

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b52db5be-5fde-4101-ad58-0f9237d93cab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU 0 & 1 not found, 9.4 & 9.5 debian, iot and lxqt

[wjbitner]

Hi!

I just picked up a beaglebone black for a new project.   I'd like to use 
the PRU's and as such tried to get
"Hello World"  from this link http://theduchy.ualr.edu/?p=996   working.
 The programs all compile but I can't get them
to run.   The major hint I have is looking at /sys/class/remoteproc/ shows 
me only remoteproc0.
PRU 0 & 1 'don't exist'.   I've not modified anything in the boot sequence 
yet.I've looked at 
https://groups.google.com/forum/#!category-topic/beagleboard/pru/4P9NdglojBo

which lead me to trying 
echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind

However, this simply gave me permission denied, despite the fact I was root.

lsmod shows

pru_rproc  28672  0
pruss  16384  1 pru_rproc
pruss_intc 16384  1 pru_rproc

but not the virtio_rpmsg_bus or other things that seem to be important.

Not sure where to go..  Any help would be appreciated.

Thanks.

Bill Bitner

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/af497214-1bf9-44d5-950c-6b84b1206dae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Cookbook

[Jason Kridner]

Announcing rev 0.1.0 of PRU Cookbook

PDF: https://github.com/beagleboard/PRUCookbook/releases/download/0.1.0/book.pdf

Live view: https://markayoder.github.io/PRUCookbook/
Source: https://github.com/markayoder/PRUCookbook/
Report issues: https://github.com/markayoder/PRUCookbook/issues


Outline

A cookbook for programming the PRUs in C using remoteproc and
compiling on the Beagle

Case Studies

✓ Robotics Control Library

✓ BeagleLogic

✓ LEDscape

✓ Falcon Player

❏ MachineKit

❏ ArduPilot

Getting started

✓ Selecting a Beagle

✓ Installing the Latest OS on Your Bone

✓ Flashing a Micro SD Card

✓ Cloud9 IDE

✓ Getting Example Code

✓ Blinking an LED

Running a Program; Configuring Pins

✓ Getting Code Example Files

✓ Compiling and Running

✓ Stopping and Starting the PRU

✓ The Standard Makefile

✓ Compiling with clpru and lnkpru

✓ The Linker Command File - AM335x_PRU.cmd

✓ Loading Firmware

✓ Configuring Pins for Controlling Servos

✓ Configuring Pins for Controlling Encoders

Debugging and Benchmarking [1]

✓ Debugging via an LED

✓ dmesg –Hw

✓ prudebug - A Simple Debugger for the PRU

✓ UART

Building Blocks – Applications

✓ Memory Allocation

✓ Auto Initialization of Built in LED Triggers

✓ PWM Generator

✓ Controlling the PWM Frequency

✓ Loop Unrolling for Better Performance

✓ Making All the Pulses Start at the Same Time

✓ Adding More Channels via PRU 1

✓ Sychronziing Two PRUs

✓ Reading an Input at Regular Intervals

✓ Analog Wave Generator

✓ WS2812 (NeoPixel) driver

✓ Setting NeoPixels to Different Colors

✓ Controlling Arbitrary LEDs

✓ Controlling NeoPixels Through a Kernel Driver

✓ RGB LED Matrix - No Integrated Drivers

✓ Compiling and Inserting rpmsg_pru

Accessing More I/O [2]

✓ /boot/uEnv.txt to access P8 I/O

✓ Accessing gpio

More Performance

✓ Calling Assembly from C

✓ Returning a Value from Assembly

✓ Using the Built In Counter for Timing

✓ Xout and Xin - Transfering Between PRUs

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPksgo2EmtaBnADPT6tYB2R%3DieU4y4GWoDksq2aKdY4nHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

[Robert Nelson]

On Mon, Sep 17, 2018 at 3:41 PM GS  wrote:
>
> Sorry I meant  if I write my own PRU overlay file while completely disabling 
> universal cape, I should still be using  "uboot_overlay_pru=" option?


Really, you can use any of them, the variable uboot_overlay_pru has
less other logic, so it's couple calls faster in u-boot's shell
script...

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjrSqyS2YeEsWazCJ4x4SyqqRWym2_M3Euuu-HmwT8CSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

[GS]

Sorry I meant  if I write my own *PRU *overlay file while completely 
disabling universal cape, I should still be using  "uboot_overlay_pru=" 
option?

On Monday, September 17, 2018 at 3:38:26 PM UTC-5, GS wrote:
>
> Thanks, Robert. I dont know how i missed that.
> Just to make sure I understand your second point correctly, if I write my 
> own overlay file while completely disabling universal cape, I should still 
> be using  "uboot_overlay_pru=" option?
>
> Thanks again
>
> On Monday, September 17, 2018 at 3:28:58 PM UTC-5, RobertCNelson wrote:
>>
>> On Mon, Sep 17, 2018 at 3:21 PM GS  wrote: 
>> > 
>> > PRU cape overlay fails to load due to pin conflicts on latest image. I 
>> have tried various setups of overlays, none seem to work. I am not sure 
>> what am I missing. 
>> > 
>> > Setup 1: [Highlighted section identifies the difference in the setup] 
>> > 
>> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
>> > [sudo] password for debian: 
>> > git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec] 
>> > eeprom:[A335BNLTEIA04816BBBK2982] 
>> > model:[TI_AM335x_BeagleBone_Black] 
>> > dogtag:[BeagleBoard.org Debian Image 2018-09-16] 
>> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>> 2018.09-2-g0b54a51eee]:[location: dd MBR] 
>> > kernel:[4.14.69-ti-r75] 
>> > nodejs:[v6.14.4] 
>> > uboot_overlay_options:[enable_uboot_overlays=1] 
>> > 
>> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
>>  
>>
>> > 
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>>  
>>
>> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
>> > pkg check: to individually upgrade run: [sudo apt install 
>> --only-upgrade ] 
>> > pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914] 
>> > pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517] 
>> > pkg:[kmod]:[23-2rcnee1~stretch+20171005] 
>> > pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830] 
>> > pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328] 
>> > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
>> admin spi tisdk weston-launch xenomai] 
>> > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>> root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>> net.ifnames=0 quiet] 
>> > dmesg | grep pinctrl-single 
>> > [1.111222] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
>> size 568 
>> > [   78.184300] pinctrl-single 44e10800.pinmux: pin PIN107 already 
>> requested by 48038000.mcasp; cannot claim for 4a30.pruss 
>> > [   78.293835] pinctrl-single 44e10800.pinmux: pin-107 (4a30.pruss) 
>> status -22 
>> > [   78.381767] pinctrl-single 44e10800.pinmux: could not request pin 
>> 107 (PIN107) from group pru_cape_bone_pins  on device pinctrl-single 
>> > dmesg | grep gpio-of-helper 
>> > [1.122976] gpio-of-helper ocp:cape-universal: ready 
>>
>> Your answer is right here ^ "48038000.mcasp; cannot claim for 
>> 4a30.pruss", you seem to be trying to use the same pru pins as the 
>> hdmi-audio.. 
>>
>> see: 
>>
>>
>> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices
>>  
>>
>> and do: 
>>
>> disable_uboot_overlay_audio=1 
>>
>> Also, for the "pru" only do the "uboot_overlay_pru=" option.. 
>>
>> Finally, any pin your define the PRU, make sure to "disable" from 
>> cape-universal in a special node as one example shown here: 
>>
>>
>> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPI0-ADS8688-0A00.dts#L36-L47
>>  
>>
>> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/46a9bf21-0c31-4322-8a6e-6412da005af5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

[GS]

Thanks, Robert. I dont know how i missed that.
Just to make sure I understand your second point correctly, if I write my 
own overlay file while completely disabling universal cape, I should still 
be using  "uboot_overlay_pru=" option?

Thanks again

On Monday, September 17, 2018 at 3:28:58 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Sep 17, 2018 at 3:21 PM GS > 
> wrote: 
> > 
> > PRU cape overlay fails to load due to pin conflicts on latest image. I 
> have tried various setups of overlays, none seem to work. I am not sure 
> what am I missing. 
> > 
> > Setup 1: [Highlighted section identifies the difference in the setup] 
> > 
> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
> > [sudo] password for debian: 
> > git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec] 
> > eeprom:[A335BNLTEIA04816BBBK2982] 
> > model:[TI_AM335x_BeagleBone_Black] 
> > dogtag:[BeagleBoard.org Debian Image 2018-09-16] 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR] 
> > kernel:[4.14.69-ti-r75] 
> > nodejs:[v6.14.4] 
> > uboot_overlay_options:[enable_uboot_overlays=1] 
> > 
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
>  
>
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>  
>
> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
> > pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ] 
> > pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914] 
> > pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517] 
> > pkg:[kmod]:[23-2rcnee1~stretch+20171005] 
> > pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830] 
> > pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328] 
> > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
> admin spi tisdk weston-launch xenomai] 
> > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet] 
> > dmesg | grep pinctrl-single 
> > [1.111222] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568 
> > [   78.184300] pinctrl-single 44e10800.pinmux: pin PIN107 already 
> requested by 48038000.mcasp; cannot claim for 4a30.pruss 
> > [   78.293835] pinctrl-single 44e10800.pinmux: pin-107 (4a30.pruss) 
> status -22 
> > [   78.381767] pinctrl-single 44e10800.pinmux: could not request pin 107 
> (PIN107) from group pru_cape_bone_pins  on device pinctrl-single 
> > dmesg | grep gpio-of-helper 
> > [1.122976] gpio-of-helper ocp:cape-universal: ready 
>
> Your answer is right here ^ "48038000.mcasp; cannot claim for 
> 4a30.pruss", you seem to be trying to use the same pru pins as the 
> hdmi-audio.. 
>
> see: 
>
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices
>  
>
> and do: 
>
> disable_uboot_overlay_audio=1 
>
> Also, for the "pru" only do the "uboot_overlay_pru=" option.. 
>
> Finally, any pin your define the PRU, make sure to "disable" from 
> cape-universal in a special node as one example shown here: 
>
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPI0-ADS8688-0A00.dts#L36-L47
>  
>
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/29ea4815-04c1-4881-983c-4553dc9adb0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

[Robert Nelson]

On Mon, Sep 17, 2018 at 3:32 PM Robert Nelson  wrote:
>
> On Mon, Sep 17, 2018 at 3:28 PM Robert Nelson  wrote:
> >
> > On Mon, Sep 17, 2018 at 3:21 PM GS  wrote:
> > >
> > > PRU cape overlay fails to load due to pin conflicts on latest image. I 
> > > have tried various setups of overlays, none seem to work. I am not sure 
> > > what am I missing.
> > >
> > > Setup 1: [Highlighted section identifies the difference in the setup]
> > >
> > > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
> > > [sudo] password for debian:
> > > git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec]
> > > eeprom:[A335BNLTEIA04816BBBK2982]
> > > model:[TI_AM335x_BeagleBone_Black]
> > > dogtag:[BeagleBoard.org Debian Image 2018-09-16]
> > > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> > > 2018.09-2-g0b54a51eee]:[location: dd MBR]
> > > kernel:[4.14.69-ti-r75]
> > > nodejs:[v6.14.4]
> > > uboot_overlay_options:[enable_uboot_overlays=1]
> > > uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
> > > uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> > > uboot_overlay_options:[enable_uboot_cape_universal=1]
> > > pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> > > ]
> > > pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914]
> > > pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> > > pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> > > pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830]
> > > pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> > > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> > > plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm 
> > > eqep admin spi tisdk weston-launch xenomai]
> > > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> > > root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> > > net.ifnames=0 quiet]
> > > dmesg | grep pinctrl-single
> > > [1.111222] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> > > size 568
> > > [   78.184300] pinctrl-single 44e10800.pinmux: pin PIN107 already 
> > > requested by 48038000.mcasp; cannot claim for 4a30.pruss
> > > [   78.293835] pinctrl-single 44e10800.pinmux: pin-107 (4a30.pruss) 
> > > status -22
> > > [   78.381767] pinctrl-single 44e10800.pinmux: could not request pin 107 
> > > (PIN107) from group pru_cape_bone_pins  on device pinctrl-single
> > > dmesg | grep gpio-of-helper
> > > [1.122976] gpio-of-helper ocp:cape-universal: ready
> >
> > Your answer is right here ^ "48038000.mcasp; cannot claim for
> > 4a30.pruss", you seem to be trying to use the same pru pins as the
> > hdmi-audio..
> >
> > see:
> >
> > https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices
> >
> > and do:
> >
> > disable_uboot_overlay_audio=1
> >
> > Also, for the "pru" only do the "uboot_overlay_pru=" option..
> >
> > Finally, any pin your define the PRU, make sure to "disable" from
> > cape-universal in a special node as one example shown here:
> >
> > https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPI0-ADS8688-0A00.dts#L36-L47
>
> I should also point out, you don't need to actually define the pru
> pin's in the overlay, instead you can use config-pin to setup the pins
> you are using for the pru.

Documented here:

https://markayoder.github.io/PRUCookbook/06io/io.html

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYj5pAjFvr5Y473CenmWroHVnHuFzjRNaFTwOAp2hriFDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

[Robert Nelson]

On Mon, Sep 17, 2018 at 3:28 PM Robert Nelson  wrote:
>
> On Mon, Sep 17, 2018 at 3:21 PM GS  wrote:
> >
> > PRU cape overlay fails to load due to pin conflicts on latest image. I have 
> > tried various setups of overlays, none seem to work. I am not sure what am 
> > I missing.
> >
> > Setup 1: [Highlighted section identifies the difference in the setup]
> >
> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
> > [sudo] password for debian:
> > git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec]
> > eeprom:[A335BNLTEIA04816BBBK2982]
> > model:[TI_AM335x_BeagleBone_Black]
> > dogtag:[BeagleBoard.org Debian Image 2018-09-16]
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> > 2018.09-2-g0b54a51eee]:[location: dd MBR]
> > kernel:[4.14.69-ti-r75]
> > nodejs:[v6.14.4]
> > uboot_overlay_options:[enable_uboot_overlays=1]
> > uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
> > uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> > uboot_overlay_options:[enable_uboot_cape_universal=1]
> > pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> > ]
> > pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914]
> > pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> > pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> > pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830]
> > pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> > plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
> > admin spi tisdk weston-launch xenomai]
> > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> > root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> > net.ifnames=0 quiet]
> > dmesg | grep pinctrl-single
> > [1.111222] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
> > 568
> > [   78.184300] pinctrl-single 44e10800.pinmux: pin PIN107 already requested 
> > by 48038000.mcasp; cannot claim for 4a30.pruss
> > [   78.293835] pinctrl-single 44e10800.pinmux: pin-107 (4a30.pruss) 
> > status -22
> > [   78.381767] pinctrl-single 44e10800.pinmux: could not request pin 107 
> > (PIN107) from group pru_cape_bone_pins  on device pinctrl-single
> > dmesg | grep gpio-of-helper
> > [1.122976] gpio-of-helper ocp:cape-universal: ready
>
> Your answer is right here ^ "48038000.mcasp; cannot claim for
> 4a30.pruss", you seem to be trying to use the same pru pins as the
> hdmi-audio..
>
> see:
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices
>
> and do:
>
> disable_uboot_overlay_audio=1
>
> Also, for the "pru" only do the "uboot_overlay_pru=" option..
>
> Finally, any pin your define the PRU, make sure to "disable" from
> cape-universal in a special node as one example shown here:
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPI0-ADS8688-0A00.dts#L36-L47

I should also point out, you don't need to actually define the pru
pin's in the overlay, instead you can use config-pin to setup the pins
you are using for the pru.

Or Jason's pru example for v4.14.x kernel's also pre-loads the pinmux values.

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhihZ25xAymQA%3DU7-RS31PAnfb2V5jXBnoiRMtgiupAMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

[Robert Nelson]

On Mon, Sep 17, 2018 at 3:21 PM GS  wrote:
>
> PRU cape overlay fails to load due to pin conflicts on latest image. I have 
> tried various setups of overlays, none seem to work. I am not sure what am I 
> missing.
>
> Setup 1: [Highlighted section identifies the difference in the setup]
>
> debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
> [sudo] password for debian:
> git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec]
> eeprom:[A335BNLTEIA04816BBBK2982]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-09-16]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR]
> kernel:[4.14.69-ti-r75]
> nodejs:[v6.14.4]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914]
> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev 
> users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi 
> tisdk weston-launch xenomai]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet]
> dmesg | grep pinctrl-single
> [1.111222] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
> 568
> [   78.184300] pinctrl-single 44e10800.pinmux: pin PIN107 already requested 
> by 48038000.mcasp; cannot claim for 4a30.pruss
> [   78.293835] pinctrl-single 44e10800.pinmux: pin-107 (4a30.pruss) 
> status -22
> [   78.381767] pinctrl-single 44e10800.pinmux: could not request pin 107 
> (PIN107) from group pru_cape_bone_pins  on device pinctrl-single
> dmesg | grep gpio-of-helper
> [1.122976] gpio-of-helper ocp:cape-universal: ready

Your answer is right here ^ "48038000.mcasp; cannot claim for
4a30.pruss", you seem to be trying to use the same pru pins as the
hdmi-audio..

see:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

and do:

disable_uboot_overlay_audio=1

Also, for the "pru" only do the "uboot_overlay_pru=" option..

Finally, any pin your define the PRU, make sure to "disable" from
cape-universal in a special node as one example shown here:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPI0-ADS8688-0A00.dts#L36-L47

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjDBsxkW7tTmp6JDs8ToAFNBOwF4W%2B0GNb14uh09B84nA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

[GS]

PRU cape overlay fails to load due to pin conflicts on latest image. I have 
tried various setups of overlays, none seem to work. I am not sure what am 
I missing.

*Setup 1*: [Highlighted section identifies the difference in the setup]

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec]
eeprom:[A335BNLTEIA04816BBBK2982]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-09-16]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.69-ti-r75]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[1.111222] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
[   78.184300] pinctrl-single 44e10800.pinmux: pin PIN107 already requested 
by 48038000.mcasp; cannot claim for 4a30.pruss
[   78.293835] pinctrl-single 44e10800.pinmux: pin-107 (4a30.pruss) 
status -22
[   78.381767] pinctrl-single 44e10800.pinmux: could not request pin 107 
(PIN107) from group pru_cape_bone_pins  on device pinctrl-single
dmesg | grep gpio-of-helper
[1.122976] gpio-of-helper ocp:cape-universal: ready
END

*Setup 2*: [Highlighted section identifies the difference in the setup]
debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec]
eeprom:[A335BNLTEIA04816BBBK2982]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-09-16]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.69-ti-r75]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[1.104064] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
[   78.558755] pinctrl-single 44e10800.pinmux: pin PIN107 already requested 
by 48038000.mcasp; cannot claim for 4a30.pruss
[   78.662225] pinctrl-single 44e10800.pinmux: pin-107 (4a30.pruss) 
status -22
[   78.756633] pinctrl-single 44e10800.pinmux: could not request pin 107 
(PIN107) from group pru_cape_bone_pins  on device pinctrl-single
dmesg | grep gpio-of-helper
[1.116205] gpio-of-helper ocp:cape-universal: ready
END

*Setup 3*:[Highlighted section identifies the difference in the setup]
debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[0726131c362e3adfcf359f3e1debf5ff156e5bec]
eeprom:[A335BNLTEIA04816BBBK2982]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-09-16]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.69-ti-r75]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]

Re: [beagleboard] PRU examples are half there

[John Syne]

BTW, I seem to remember that I had to modify the code to work because RPMSG use 
to use mailbox to exchange messages, but that was changed to use Interrupts.  I 
believe Jason Reeder from TI helped me get this working. 

Regards,
John





> On May 7, 2018, at 12:47 PM, Mark A. Yoder  wrote:
> 
> John:
>   That's a great help.  Is the documentation for the example?
> 
> --Mark
> 
> On Monday, May 7, 2018 at 3:01:54 PM UTC-4, john3909 wrote:
> https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c
>  
> 
> 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On May 7, 2018, at 8:19 AM, Mark A. Yoder > wrote:
>> 
>> Yup, all I see is the PRU code, no ARM code.
>> 
>> --Mark
>> 
>> On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
>> Did you look at http://git.ti.com/pru-software-support-package 
>>  ?
>> 
>> On May 4, 2018, at 5:08 PM, Mark A. Yoder > wrote:
>> 
>>> I'm starting to build up some remoteproc-based examples for the PRU and 
>>> found a bunch of examples here:  
>>> /usr/lib/ti/pru-software-support-package/examples.
>>> 
>>> But the examples are only half there.  That is, the code is present for the 
>>> PRU side but not the ARM side.
>>> 
>>> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an 
>>> interrupt to the ARM, but there is no example code for the ARM side.
>>> 
>>> Anyone know where the ARM code is?
>>> 
>>> Thanks...
>>> 
>>> --Mark
>>> 
>>> -- 
>>> 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 beagleboard...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com
>>>  
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>> 
>> 
>> -- 
>> 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 beagleboard...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> 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 beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/807cdbb4-3cf2-4086-ae1a-319ff4f5d4e1%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/07260740-530F-4A49-BEA4-27D83FFDA9FF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

[John Syne]

Yeah, I haven’t worked on this for a while, but from what I remember, the ARM 
side sends out 200 ping messages to the PRU and the PRU responds to each 
interrupt with a reply, which the ARM side prints out. Look for the PING 
example for the PRU, load the firmware and then load this Kernel Module. 

Regards,
John

Regards,
John





> On May 7, 2018, at 12:47 PM, Mark A. Yoder  wrote:
> 
> John:
>   That's a great help.  Is the documentation for the example?
> 
> --Mark
> 
> On Monday, May 7, 2018 at 3:01:54 PM UTC-4, john3909 wrote:
> https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c
>  
> 
> 
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On May 7, 2018, at 8:19 AM, Mark A. Yoder > wrote:
>> 
>> Yup, all I see is the PRU code, no ARM code.
>> 
>> --Mark
>> 
>> On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
>> Did you look at http://git.ti.com/pru-software-support-package 
>>  ?
>> 
>> On May 4, 2018, at 5:08 PM, Mark A. Yoder > wrote:
>> 
>>> I'm starting to build up some remoteproc-based examples for the PRU and 
>>> found a bunch of examples here:  
>>> /usr/lib/ti/pru-software-support-package/examples.
>>> 
>>> But the examples are only half there.  That is, the code is present for the 
>>> PRU side but not the ARM side.
>>> 
>>> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an 
>>> interrupt to the ARM, but there is no example code for the ARM side.
>>> 
>>> Anyone know where the ARM code is?
>>> 
>>> Thanks...
>>> 
>>> --Mark
>>> 
>>> -- 
>>> 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 beagleboard...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com
>>>  
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>> 
>> 
>> -- 
>> 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 beagleboard...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> 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 beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/807cdbb4-3cf2-4086-ae1a-319ff4f5d4e1%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5759B607-1D37-455A-9691-48323953FA8D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

['Mark Lazarewicz' via BeagleBoard]

I remember seeing both sides of the code for this interrupt example but it was 
for bare bone NOT linux.  Its been 6 months and I'm not sure if that helps you. 
My focus/interest  is primarily the chip level(register level) not API(remote 
proc). If it your interested I could do some digging. I want to say I saw it on 
a wiki for omap l138 I was working on which is ARM + PRU + DSP


Sent from Yahoo Mail on Android 
 
  On Fri, May 4, 2018 at 4:08 PM, Mark A. Yoder wrote:  
 I'm starting to build up some remoteproc-based examples for the PRU and found 
a bunch of examples here:  /usr/lib/ti/pru-software-support-package/examples.
But the examples are only half there.  That is, the code is present for the PRU 
side but not the ARM side.
For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an interrupt to 
the ARM, but there is no example code for the ARM side.
Anyone know where the ARM code is?
Thanks...
--Mark

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1496478417.864423.1525725750120%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

[Mark A. Yoder]

John:
  That's a great help.  Is the documentation for the example?

--Mark

On Monday, May 7, 2018 at 3:01:54 PM UTC-4, john3909 wrote:
>
>
> https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c
>
>
> Regards,
> John
>
>
>
>
>
> On May 7, 2018, at 8:19 AM, Mark A. Yoder  > wrote:
>
> Yup, all I see is the PRU code, no ARM code.
>
> --Mark
>
> On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
>>
>> Did you look at http://git.ti.com/pru-software-support-package ?
>>
>> On May 4, 2018, at 5:08 PM, Mark A. Yoder  wrote:
>>
>> I'm starting to build up some remoteproc-based examples for the PRU and 
>> found a bunch of examples here:  
>> */usr/lib/ti/pru-software-support-package/examples*.
>>
>> But the examples are only *half* there.  That is, the code is present 
>> for the PRU side but not the ARM side.
>>
>> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an 
>> interrupt to the ARM, but there is no example code for the ARM side.
>>
>> Anyone know where the ARM code is?
>>
>> Thanks...
>>
>> --Mark
>>
>> -- 
>> 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 beagleboard...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
> -- 
> 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 beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/807cdbb4-3cf2-4086-ae1a-319ff4f5d4e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

[John Syne]

https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c
 



Regards,
John





> On May 7, 2018, at 8:19 AM, Mark A. Yoder  wrote:
> 
> Yup, all I see is the PRU code, no ARM code.
> 
> --Mark
> 
> On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
> Did you look at http://git.ti.com/pru-software-support-package 
>  ?
> 
> On May 4, 2018, at 5:08 PM, Mark A. Yoder > wrote:
> 
>> I'm starting to build up some remoteproc-based examples for the PRU and 
>> found a bunch of examples here:  
>> /usr/lib/ti/pru-software-support-package/examples.
>> 
>> But the examples are only half there.  That is, the code is present for the 
>> PRU side but not the ARM side.
>> 
>> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an interrupt 
>> to the ARM, but there is no example code for the ARM side.
>> 
>> Anyone know where the ARM code is?
>> 
>> Thanks...
>> 
>> --Mark
>> 
>> -- 
>> 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 beagleboard...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> 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 beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C3E4538C-4265-479F-99E9-ECB61F6C9515%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

[Mark A. Yoder]

Yup, all I see is the PRU code, no ARM code.

--Mark

On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote:
>
> Did you look at http://git.ti.com/pru-software-support-package ?
>
> On May 4, 2018, at 5:08 PM, Mark A. Yoder  > wrote:
>
> I'm starting to build up some remoteproc-based examples for the PRU and 
> found a bunch of examples here:  
> */usr/lib/ti/pru-software-support-package/examples*.
>
> But the examples are only *half* there.  That is, the code is present for 
> the PRU side but not the ARM side.
>
> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an 
> interrupt to the ARM, but there is no example code for the ARM side.
>
> Anyone know where the ARM code is?
>
> Thanks...
>
> --Mark
>
> -- 
> 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 beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dd58c3be-b544-49a2-b869-b82e9c27753e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU examples are half there

[Jason Kridner]

Did you look at http://git.ti.com/pru-software-support-package ?

> On May 4, 2018, at 5:08 PM, Mark A. Yoder  wrote:
> 
> I'm starting to build up some remoteproc-based examples for the PRU and found 
> a bunch of examples here:  /usr/lib/ti/pru-software-support-package/examples.
> 
> But the examples are only half there.  That is, the code is present for the 
> PRU side but not the ARM side.
> 
> For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an interrupt 
> to the ARM, but there is no example code for the ARM side.
> 
> Anyone know where the ARM code is?
> 
> Thanks...
> 
> --Mark
> -- 
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/AE4B2F96-5352-44E0-9F69-EEC5D11B2357%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU examples are half there

[Mark A. Yoder]

I'm starting to build up some remoteproc-based examples for the PRU and 
found a bunch of examples here:  
*/usr/lib/ti/pru-software-support-package/examples*.

But the examples are only *half* there.  That is, the code is present for 
the PRU side but not the ARM side.

For example, PRU_PRUtoARM_Inaterrupt shows the PRU code to send an 
interrupt to the ARM, but there is no example code for the ARM side.

Anyone know where the ARM code is?

Thanks...

--Mark

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9c16071c-5e4e-4f31-8525-80607da71f74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU with internal ADC question

[Chad Baker]

From Vega's line 62

 fifo0_count = HWREG(0x44e0d0e4);

Go to the TRM(spruh73p search at ti.com), chapter 2, Table 2-2
Look for region name ADC_TSC, Start Address 0x44E0_D000 to End Address 
0x44E0_EFFF

So you are looking for register at offset 0x00E4
click on the ADC-TSC link or look for Table 12.5.1 TSC_ADC_SS Registers
look for offset e4, that is register STEPDELAY16, follow the link to 
12.5.1.50

the table 12-54 gives the register field description.
The TRM is a good reference, the URL might change so downloading might 
be advisable, but
knowing how to find the latest "spruh73" manual is also a good exercise 
to master.

Chad

On 4/27/18 8:12 AM, maique.gar...@gmail.com wrote:


Hi friends. Im trying to use the BBB built-in ADC to read values with 
regular sampling frequency. I am using almost all defined by Rafael 
Vega's github project page  
(https://github.com/rvega/bbb-pru/blob/master/apps/adc/pru.c 
). I 
already made changes to read the ADC sampled values on the ARM program 
and everithing are working fine. BUT i have 2 questions about this 
program:


1) I want to know how he knows the necessaries BBB registers to 
configurate the ADC and the communication pipe between ADC and PRUs on 
this setup? I already looked the PRUSS and SITARA doccumentation but 
with no match the registers names used by him.


2) how i can calculate the sampling frequency? I found on his page 
that it was configured to 50 ksps but, trying to calculate this 
sampling frequency on the gived formula:


// fs = 24MHz / (CLK_DIV*2*Channels*(OpenDly+Average*(14+SampleDly))) 
(on line 108 from the link above)


I didn't get an integer fs value, for example, using their specified 
values (clock_divider = 4;  open_delay = 4;  average = 1; sample_delay 
= 4; and channel = 6) i get 22727.2727273 Hz.. Am i missing something?


Thanks for all..
--
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 beagleboard+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c513a004-87b2-4b62-b4c8-991c42631b25%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2be9b1da-1d3a-8f53-e505-bcc7b90eaef6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU with internal ADC question

[maique . garcia]

Hi friends. Im trying to use the BBB built-in ADC to read values with 
regular sampling frequency. I am using almost all defined by Rafael Vega's 
github project page  (
https://github.com/rvega/bbb-pru/blob/master/apps/adc/pru.c). I already 
made changes to read the ADC sampled values on the ARM program and 
everithing are working fine. BUT i have 2 questions about this program:

1) I want to know how he knows the necessaries BBB registers to configurate 
the ADC and the communication pipe between ADC and PRUs on this setup? I 
already looked the PRUSS and SITARA doccumentation but with no match the 
registers names used by him.

2) how i can calculate the sampling frequency? I found on his page that it 
was configured to 50 ksps but, trying to calculate this sampling frequency 
on the gived formula:

// fs = 24MHz / (CLK_DIV*2*Channels*(OpenDly+Average*(14+SampleDly))) (on 
line 108 from the link above)
I didn't get an integer fs value, for example, using their specified values 
(clock_divider = 4;  open_delay = 4;  average = 1; sample_delay = 4; 
and channel = 6) i get 22727.2727273 Hz.. Am i missing something? 

Thanks for all..

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c513a004-87b2-4b62-b4c8-991c42631b25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU-UIO specified, but lsmod shows pru_rproc?

[Robert Nelson]

On Mon, Mar 12, 2018 at 7:50 PM, Rick Mann  wrote:
> Oh. I finally found this tiny note on 
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays:
>
> (doesn't work with v4.9.x-ti yet)
>
> That same page says remoteproc works on v4.4.x-ti, so I'm not sure if the 
> current IoT image is supposed to be able to use the PRU at all.

Just remoteproc_pruss for v4.9.x-ti, for "uio_pruss" i need to spend
some time writing up the other things you need to disable to get it to
work..

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhmk5o5i_nq9vWmDu3eXHpT3ixmym9FQCnJdPC%3D_FADZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU-UIO specified, but lsmod shows pru_rproc?

[Rick Mann]

Oh. I finally found this tiny note on 
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays:

(doesn't work with v4.9.x-ti yet)

That same page says remoteproc works on v4.4.x-ti, so I'm not sure if the 
current IoT image is supposed to be able to use the PRU at all.

> On Mar 12, 2018, at 05:07 , Rick Mann  wrote:
> 
> On the recent IoT (March 2018) standalone build, on BBB:
> 
> I'm trying to enable uio PRUSS, and in /boot/uEnv.txt I uncommented
> 
>   uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
> 
> But after rebooting, it seems (I think?) that remoteproc is still what's 
> loaded:
> 
> $ lsmod
> Module  Size  Used by
> pruss_soc_bus   4788  0
> evdev  13811  1
> uio_pdrv_genirq 4205  0
> uio11036  1 uio_pdrv_genirq
> 8021q  24278  0
> usb_f_mass_storage 51462  2
> garp7357  1 8021q
> mrp 9301  1 8021q
> stp 2686  1 garp
> llc 6287  2 garp,stp
> usb_f_acm   8610  2
> u_serial   13482  3 usb_f_acm
> usb_f_ecm  11619  2
> usb_f_rndis26944  2
> u_ether13962  2 usb_f_ecm,usb_f_rndis
> libcomposite   55456  16 
> usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis
> iptable_nat 2512  0
> nf_conntrack_ipv4  12035  1
> nf_defrag_ipv4  2016  1 nf_conntrack_ipv4
> nf_nat_ipv4 6857  1 iptable_nat
> nf_nat 18928  1 nf_nat_ipv4
> nf_conntrack  117486  3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
> iptable_mangle  2303  0
> iptable_filter  2453  0
> spidev  9322  0
> pru_rproc  14966  0
> pruss_intc  9092  1 pru_rproc
> pruss  10889  1 pru_rproc
> tieqep  9111  0
> ip_tables  14529  3 iptable_mangle,iptable_filter,iptable_nat
> x_tables   22165  3 iptable_mangle,ip_tables,iptable_filter
> 
> $ ls /sys/class/uio/
> $
> 
> $ dmesg | grep pru
> [   71.203962] sysfs: cannot create duplicate filename 
> '/bus/platform/devices/4a30.pruss'
> [   71.203968] Modules linked in: pruss_soc_bus(+) evdev uio_pdrv_genirq uio 
> 8021q usb_f_mass_storage garp mrp stp llc usb_f_acm u_serial usb_f_ecm 
> usb_f_rndis u_ether libcomposite iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
> nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter spidev 
> pru_rproc pruss_intc pruss tieqep ip_tables x_tables
> [   71.210212] [] (of_platform_populate) from [] 
> (pruss_soc_bus_probe+0x12c/0x290 [pruss_soc_bus])
> [   71.210260] [] (pruss_soc_bus_probe [pruss_soc_bus]) from 
> [] (platform_drv_probe+0x60/0xc0)
> [   71.210360] [] (__platform_driver_register) from [] 
> (pruss_soc_bus_driver_init+0x20/0xc0 [pruss_soc_bus])
> [   71.210382] [] (pruss_soc_bus_driver_init [pruss_soc_bus]) from 
> [] (do_one_initcall+0x64/0x1a0)
> 
> 
> In any case, if I try to prussdrv_open(PRU_EVTOUT_0), I get '-1: No such file 
> or directory'. Am I missing a step?
> 
> Thanks!
> 
> -- 
> Rick Mann
> rm...@latencyzero.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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/FCB6661A-CA22-4C78-8694-190FE3F6E676%40latencyzero.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
Rick Mann
rm...@latencyzero.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7A782F52-BB27-4BCE-AD1A-10E5E79B9167%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU-UIO specified, but lsmod shows pru_rproc?

[Rick Mann]

On the recent IoT (March 2018) standalone build, on BBB:

I'm trying to enable uio PRUSS, and in /boot/uEnv.txt I uncommented

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

But after rebooting, it seems (I think?) that remoteproc is still what's loaded:

$ lsmod
Module  Size  Used by
pruss_soc_bus   4788  0
evdev  13811  1
uio_pdrv_genirq 4205  0
uio11036  1 uio_pdrv_genirq
8021q  24278  0
usb_f_mass_storage 51462  2
garp7357  1 8021q
mrp 9301  1 8021q
stp 2686  1 garp
llc 6287  2 garp,stp
usb_f_acm   8610  2
u_serial   13482  3 usb_f_acm
usb_f_ecm  11619  2
usb_f_rndis26944  2
u_ether13962  2 usb_f_ecm,usb_f_rndis
libcomposite   55456  16 
usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis
iptable_nat 2512  0
nf_conntrack_ipv4  12035  1
nf_defrag_ipv4  2016  1 nf_conntrack_ipv4
nf_nat_ipv4 6857  1 iptable_nat
nf_nat 18928  1 nf_nat_ipv4
nf_conntrack  117486  3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
iptable_mangle  2303  0
iptable_filter  2453  0
spidev  9322  0
pru_rproc  14966  0
pruss_intc  9092  1 pru_rproc
pruss  10889  1 pru_rproc
tieqep  9111  0
ip_tables  14529  3 iptable_mangle,iptable_filter,iptable_nat
x_tables   22165  3 iptable_mangle,ip_tables,iptable_filter

$ ls /sys/class/uio/
$

$ dmesg | grep pru
[   71.203962] sysfs: cannot create duplicate filename 
'/bus/platform/devices/4a30.pruss'
[   71.203968] Modules linked in: pruss_soc_bus(+) evdev uio_pdrv_genirq uio 
8021q usb_f_mass_storage garp mrp stp llc usb_f_acm u_serial usb_f_ecm 
usb_f_rndis u_ether libcomposite iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter spidev pru_rproc 
pruss_intc pruss tieqep ip_tables x_tables
[   71.210212] [] (of_platform_populate) from [] 
(pruss_soc_bus_probe+0x12c/0x290 [pruss_soc_bus])
[   71.210260] [] (pruss_soc_bus_probe [pruss_soc_bus]) from 
[] (platform_drv_probe+0x60/0xc0)
[   71.210360] [] (__platform_driver_register) from [] 
(pruss_soc_bus_driver_init+0x20/0xc0 [pruss_soc_bus])
[   71.210382] [] (pruss_soc_bus_driver_init [pruss_soc_bus]) from 
[] (do_one_initcall+0x64/0x1a0)


In any case, if I try to prussdrv_open(PRU_EVTOUT_0), I get '-1: No such file 
or directory'. Am I missing a step?

Thanks!

-- 
Rick Mann
rm...@latencyzero.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/FCB6661A-CA22-4C78-8694-190FE3F6E676%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU based frequency detection and measuremnt-

[Hithesh Karanth]

kernel 3.8.x 
Thanks for the effort for addressing this problem in advance.
The following assembler and python files concists of my code to measure 
frequencies on the respectiver ports P8_15 and P8_16 using PRU0. The only 
problem being the outout of one of those frequency measured is always 
fluctuatung by a large margin (does show the actual output sometimes). I 
agree with the fact that this code can handle frequency measurement at one 
ports flawlessly I have checked for overflow of memory assigned at the 
shared ram and I can confirm that the flaw in output is not due to the 
overflow. 
Any help would be appreseated.
Thank you.

The following code is assembler code I have been using-
.origin 0

#define PRU0_ARM_INTERRUPT 19

#define CONST_PRUCFG C4
#define CONST_PRUSHAREDRAM   C28
 
#define PRU0_CTRL0x22000
#define PRU1_CTRL0x24000
 
#define CTPPR0   0x28
 
#define OWN_RAM  0x000
#define OTHER_RAM0x020
#define SHARED_RAM   0x100

#define SECOND   2  // 2e8 5ns cycles
#define DELAY  200  // 0.01 s

START:
lbco r0, CONST_PRUCFG, 4, 4  // Enable OCP master port
clr  r0, r0, 4
sbco r0, CONST_PRUCFG, 4, 4

mov  r0, SHARED_RAM  // Set C28 to point to shared RAM
mov  r1, PRU0_CTRL + CTPPR0
sbbo r0, r1, 0, 4

mov  r2.w0, DELAY & 0x
mov  r2.w2, DELAY >> 16 

WAITLO:
qbbc WAITLO, r31.t15

IGNORE:  // Wait for 50 consecutive readings of 
1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE, r0, r2

WAIT1: // Continue counting while input is 
still 1
add  r0, r0, 2
qbbs WAIT1, r31.t15

WAIT2: // Continue counting while input is 0
add  r0, r0, 2
qbbc WAIT2, r31.t15// End count when input goes to 1

sbco r0, CONST_PRUSHAREDRAM, 0, 4  // Write count to RAM
MOV R31.b0, PRU0_ARM_INTERRUPT+16   // Send notification to Host for 
program completion
mov r0,0

WAITLO1:
qbbc WAITLO1, r31.t14


IGNORE1:  // Wait for 50 consecutive readings 
of 1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE1, r0, r2

  
WAIT3: // Continue counting while input is 
still 1
add  r0, r0, 2
qbbs WAIT3, r31.t14

WAIT4: // Continue counting while input is 0
add  r0, r0, 2
qbbc WAIT4, r31.t14// End count when input goes to 1

sbco r0, CONST_PRUSHAREDRAM,8 , 4  // Write count to RAM
MOV R31.b0, PRU0_ARM_INTERRUPT+16   // Send notification to Host for 
program completion
mov  r0, 0
jmp  IGNORE

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6b215820-55c9-4757-84f2-9f289c8dae19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
.origin 0

#define PRU0_ARM_INTERRUPT 19

#define CONST_PRUCFG C4
#define CONST_PRUSHAREDRAM   C28
 
#define PRU0_CTRL0x22000
#define PRU1_CTRL0x24000
 
#define CTPPR0   0x28
 
#define OWN_RAM  0x000
#define OTHER_RAM0x020
#define SHARED_RAM   0x100

#define SECOND   2  // 2e8 5ns cycles
#define DELAY  200  // 0.01 s

START:
lbco r0, CONST_PRUCFG, 4, 4  // Enable OCP master port
clr  r0, r0, 4
sbco r0, CONST_PRUCFG, 4, 4

mov  r0, SHARED_RAM  // Set C28 to point to shared RAM
mov  r1, PRU0_CTRL + CTPPR0
sbbo r0, r1, 0, 4

mov  r2.w0, DELAY & 0x
mov  r2.w2, DELAY >> 16 

WAITLO:
qbbc WAITLO, r31.t15

IGNORE:  // Wait for 50 consecutive readings of 1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE, r0, r2

WAIT1: // Continue counting while input is still 1
add  r0, r0, 2
qbbs WAIT1, r31.t15

WAIT2: // Continue counting while input is 0
add  r0, r0, 2
qbbc WAIT2, r31.t15// End count when input goes to 1

sbco r0, CONST_PRUSHAREDRAM, 0, 4  // Write count to RAM
MOV R31.b0, PRU0_ARM_INTERRUPT+16   // Send notification to Host for program completion
mov r0,0

WAITLO1:
qbbc WAITLO1, r31.t14


IGNORE1:  // Wait for 50 consecutive readings of 1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE1, r0, r2

  
WAIT3: // 

[beagleboard] PRU based frequency measurement

[Hithesh Karanth]

kernel 3.8.x 
Thanks for the effort for addressing this problem in advance.
The following assembler and python files concists of my code to measure 
frequencies on the respectiver ports P8_15 and P8_16 using PRU0. The only 
problem being the outout of one of those frequency measured is always 
fluctuatung by a large margin (does show the actual output sometimes). I 
agree with the fact that this code can handle frequency measurement at one 
ports flawlessly I have checked for overflow of memory assigned at the 
shared ram and I can confirm that the flaw in output is not due to the 
overflow. 
Any help would be appreseated.
Thank you.

The following code is assembler code I have been using-
.origin 0

#define PRU0_ARM_INTERRUPT 19

#define CONST_PRUCFG C4
#define CONST_PRUSHAREDRAM   C28
 
#define PRU0_CTRL0x22000
#define PRU1_CTRL0x24000
 
#define CTPPR0   0x28
 
#define OWN_RAM  0x000
#define OTHER_RAM0x020
#define SHARED_RAM   0x100

#define SECOND   2  // 2e8 5ns cycles
#define DELAY  200  // 0.01 s

START:
lbco r0, CONST_PRUCFG, 4, 4  // Enable OCP master port
clr  r0, r0, 4
sbco r0, CONST_PRUCFG, 4, 4

mov  r0, SHARED_RAM  // Set C28 to point to shared RAM
mov  r1, PRU0_CTRL + CTPPR0
sbbo r0, r1, 0, 4

mov  r2.w0, DELAY & 0x
mov  r2.w2, DELAY >> 16 

WAITLO:
qbbc WAITLO, r31.t15

IGNORE:  // Wait for 50 consecutive readings of 
1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE, r0, r2

WAIT1: // Continue counting while input is 
still 1
add  r0, r0, 2
qbbs WAIT1, r31.t15

WAIT2: // Continue counting while input is 0
add  r0, r0, 2
qbbc WAIT2, r31.t15// End count when input goes to 1

sbco r0, CONST_PRUSHAREDRAM, 0, 4  // Write count to RAM
MOV R31.b0, PRU0_ARM_INTERRUPT+16   // Send notification to Host for 
program completion
mov r0,0

WAITLO1:
qbbc WAITLO1, r31.t14


IGNORE1:  // Wait for 50 consecutive readings 
of 1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE1, r0, r2

  
WAIT3: // Continue counting while input is 
still 1
add  r0, r0, 2
qbbs WAIT3, r31.t14

WAIT4: // Continue counting while input is 0
add  r0, r0, 2
qbbc WAIT4, r31.t14// End count when input goes to 1

sbco r0, CONST_PRUSHAREDRAM,8 , 4  // Write count to RAM
MOV R31.b0, PRU0_ARM_INTERRUPT+16   // Send notification to Host for 
program completion
mov  r0, 0
jmp  IGNORE

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/49b23fd1-6bb5-4a65-9a8f-38dec3469e68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
.origin 0

#define PRU0_ARM_INTERRUPT 19

#define CONST_PRUCFG C4
#define CONST_PRUSHAREDRAM   C28
 
#define PRU0_CTRL0x22000
#define PRU1_CTRL0x24000
 
#define CTPPR0   0x28
 
#define OWN_RAM  0x000
#define OTHER_RAM0x020
#define SHARED_RAM   0x100

#define SECOND   2  // 2e8 5ns cycles
#define DELAY  200  // 0.01 s

START:
lbco r0, CONST_PRUCFG, 4, 4  // Enable OCP master port
clr  r0, r0, 4
sbco r0, CONST_PRUCFG, 4, 4

mov  r0, SHARED_RAM  // Set C28 to point to shared RAM
mov  r1, PRU0_CTRL + CTPPR0
sbbo r0, r1, 0, 4

mov  r2.w0, DELAY & 0x
mov  r2.w2, DELAY >> 16 

WAITLO:
qbbc WAITLO, r31.t15

IGNORE:  // Wait for 50 consecutive readings of 1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE, r0, r2

WAIT1: // Continue counting while input is still 1
add  r0, r0, 2
qbbs WAIT1, r31.t15

WAIT2: // Continue counting while input is 0
add  r0, r0, 2
qbbc WAIT2, r31.t15// End count when input goes to 1

sbco r0, CONST_PRUSHAREDRAM, 0, 4  // Write count to RAM
MOV R31.b0, PRU0_ARM_INTERRUPT+16   // Send notification to Host for program completion
mov r0,0

WAITLO1:
qbbc WAITLO1, r31.t14


IGNORE1:  // Wait for 50 consecutive readings of 1
add  r0, r0, 2 // 3 cycles per loop
qbgt IGNORE1, r0, r2

  
WAIT3: // Continue 

[beagleboard] PRU - ARM Communication

[karanth . hithesh]

Greetings,

Thanks for all who will make an effort to answer my querry in advance. I am 
using Beaglebone Black Rev C with 3.8.x kernel and I'm stuck with 
establishng inter-communication between one of the cores of the PRU to the 
main ARM core where the OS lies.Requirement-

The PRU requires a variable which counts number of loops and post execution 
of this program the OS should have the accessibility to get the data inside 
this variable and use it to display the number of counts that has happened 
during program execution.

Questions-

1.How to load the data onto so register such that it can be accesible in 
ARM or OS end?

2.How to access PRU written data and using it in OS?

3.I have heard a lot about shared RAM used in similar process so does it 
impy to my application as well? If so how to implement it?

Note: I'm using Python at the OS end, Assembly language to program PRU and 
a C program to load the Assebly.bin file to PRU for execution.

Thanks for the help .

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/78402260-dfb8-412f-ae88-6ff59d6c2df4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU programming with pasm compiled .bin hangup - prussdrv_open() failed

[evangrcarter]

Hello,

I've been playing with this Beaglebone Black Wireless for several months 
now, and I feel like I've come pretty far from out-right newbie status, but 
after struggling for so long to program one of the BBBW's PRUs I'm starting 
to feel like a newbie again. Please help!

I've been following this tutorial 
- http://credentiality2.blogspot.com/2015/09/beaglebone-pru-gpio-example.html  
- mostly because it makes intuitive sense to me.

It says that to program the PRU, you have to use a device tree overlay to 
set up the gpios pins and their configuration for the PRU to be able to use 
them, then you have to write a .c program to load assembly code into the 
PRU after you compile it into .bin with ./pasm. This all seems relatively 
simple, and I've been able to get everything to compile and I can load my 
overlay into /sys/devices/platform/bone_capemgr/slots with no issues. But 
as soon as I try to load my compiled assembly code into the PRU with:

"./pru_loader pru_gpio_test.bin" - as instructed by the tutorial

I get the error "prussdrv_open() failed"

Can anyone help me please?? I'm so stuck and I'm not finding information on 
existing threads that works for me.

my uname -a read out is:
Linux beaglebone 4.9.45-ti-r57 #1 SMP PREEMPT Fri Aug 25 22:58:38 UTC 2017 
armv7l GNU/Linux

when I run lsmod |grep pru :
pruss_soc_bus   4788  0
pru_rproc  14966  0
pruss_intc  9092  1 pru_rproc
pruss  10889  1 pru_rproc

I haven't altered the pru_loader.c code at all from what is shown on the 
tutorial page, and I only made minor adjustments to the .dts file and 
assembly code. I will provide those if it helps.

Thank you for reading! Please get back to me soon!
evangrcar...@gmail.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6c3bdb52-2501-4eaf-816d-f5476609ec98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU/DDR Feasibility

[David Edwards]

I'm looking at moving away from an FPGA to a PocketBeagle for a new 
project, and I think I can divide up my real-time tasks between the 2 PRU's:
   
   1. Use PRU0 as a SPI master to capture external 16-bit ADC data at 
   500kS/s
   2. Store around 30MB of samples in DDR
   3. Change PRU0 firmware to be a SPI slave to transfer these samples to 
   an external host with a SPI clock rate in the neighborhood of 40MHz 
   (~2.5MB/s)
   4. PRU1 will act as an I2C slave handling stop/start/config requests for 
   the two PRU0 activities.

I'm a little concerned about the DDR transfer in step 3 keeping up with the 
SPI clock rate.  Will this transfer be subject to possible latencies in the 
non-RTOS core?  Or, is there a way to architect this where PRU0 has direct 
access to the 512MB external memory?  The linux core does not necessarily 
need to see or even know about this data, I simply need to store it and 
then dump it back out.


Thanks,

Dave

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ab5b17e1-a89f-41c0-b772-0f29b55b7855%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU shared with Node-Red ??

[Michael Dalby]

Hi,


I wondered if there was a way to make a program running in the PRU 
available to a Node-Red implementation running on the same BBB??


For example if I had the PRU doing serial communications, could I 
read/export any data into a Node-Red flow?


Kind regards

Michael

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cd4207c4-54f5-4abd-b8a9-e68153eb1403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU

[Rick Reynolds]

This github is great for getting started with the PRUs. Cuts right to the chase 
and provides examples for all the required files.

Thanks Jason.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9970245b-fadc-42cf-ac8c-e31321469d61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU

[Jason Kridner]

On Sat, Oct 7, 2017 at 5:18 PM William Hermans  wrote:

> On Fri, Oct 6, 2017 at 11:38 PM,  wrote:
>
>> Hi,
>>
>> Hi, I am new to beaglebone black PRU can anybody help me to use PRU in
>> c-language.
>>
>> Thank you
>> Ashok
>>
>
> http://lmgtfy.com/?q=beaglebone+PRU+in+C
>

To try to get some better results the first time, I tried to summarize some
PRU programming info at http://bbb.io/pru.

At the very bottom, you'll see a link to a more recent demo I put together
to show how to program the PRU in C.
https://gist.github.com/jadonk/2ecf864e1b3f250bad82c0eae12b7b64

It is pretty simple. I started by blinking the on-board LED. To make it
more fun, I reduced the delay every cycle so that the blinking speeds up.


>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CALHSORrd3W1PynvSu9nYSMddVm7zjjyf5yzR%3DoXM_bbDMkZxsw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
https://beagleboard.org/about

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QP%3Dn6i9JrVZapDE2sEv37GPBYi2v%3Dn70cruRM%2BVNrpO7Hw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU

[William Hermans]

On Fri, Oct 6, 2017 at 11:38 PM,  wrote:

> Hi,
>
> Hi, I am new to beaglebone black PRU can anybody help me to use PRU in
> c-language.
>
> Thank you
> Ashok
>

http://lmgtfy.com/?q=beaglebone+PRU+in+C

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrd3W1PynvSu9nYSMddVm7zjjyf5yzR%3DoXM_bbDMkZxsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU

[ashokkumar1232014]

Hi,

Hi, I am new to beaglebone black PRU can anybody help me to use PRU in 
c-language.

Thank you
Ashok

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/179de89d-858c-47d6-b611-bfa27abdb718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU DDR ram allocation using 4.4.54 kernel (uio or rproc?)

[bodetechnics]

Hi all

I am currently trying to get the EBB-PRU-ADC example from Derek Molloys website 
working on my new version of Debian.

I am using kernel version;
uname -r
4.4.54-ti-r93

In this later kernel, uio_pruss is no longer used and remote proc has now taken 
over.

I have already gone through the pain of getting the EBB_PRU_ADC overlay to load 
by disabling the universaln cape and then recompiling Dereks overlay with the 
newer dtc compiler.

The overlay has loaded successfully;

cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1 
 1: PF  -1 
 2: PF  -1 
 3: PF  -1 
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-PRU-ADC

However, I need to increase the sram pool size and extram pool size as follows;


sram_pool_sz – SRAM pool size to allocate (default 16K).
extram_pool_sz – The external RAM pool size to allocate (default 256K).

My kernel now uses remote proc instead of uio_pruss and I am struggling to work 
out how to achieve this.

How do I go about this with the modules that are loaded such as;

lsmod |grep pru
pru_rproc  15431  0 
pruss_intc  8603  1 pru_rproc
pruss  12026  1 pru_rproc

Should I be trying to use uio_pruss or can I do it through the rproc module?

Any help would be highly appreciated!

Thanks

B




-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0788cc63-5a48-4570-9260-5d4c61117ebd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru support for 4.4.84-ti-r120

[Robert Nelson]

On Tue, Sep 5, 2017 at 11:03 AM, Kasimir  wrote:
> I want to use the HDMI outputs to drive external circuit. Required toggle
> rate is between 1MHz and 10MHz.
> Have BB black.
> uname -a
> Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 armv7l
> GNU/Linux
> cat /etc/debian_version
> 9.1
> So I have to use the PRU unit.
> I was searching example to have a starting point.
> But it sucks already with the first step.
>
> ll /sys/devices/bone_capemgr*
> ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory
>
> I load the image from here:
> http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz
>
> What is my mistake?
> Device tree compiler is up to date
> device-tree-compiler is already the newest version
> (1.4.4-0rcnee3~stretch+20170719).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> Found a lot of hints to use the 3.8 kernel. Think that one is already some
> years old, can't be true.
>
> Question: How to create the required device tree overlay, because
> /sys/devices/bone_capemgr* is not existing?

That was the 3.8.13 location, this changed in 4.1.x+

For that newer image it's using u-boot overlays:

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

to disable hdmi follow:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

and

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

if you have any problem run:

sudo  /opt/scripts/tools/version.sh

and we can debug what wrong..

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgf3Lf9U8tBqZR3-FA5%3DSsYAxdbB7Hp3_Y9SyK%2B0rXcHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] pru support for 4.4.84-ti-r120

[Kasimir]

I want to use the HDMI outputs to drive external circuit. Required toggle 
rate is between 1MHz and 10MHz.
Have BB black.
uname -a
Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 armv7l 
GNU/Linux
cat /etc/debian_version 
9.1
So I have to use the PRU unit.
I was searching example to have a starting point.
But it sucks already with the first step.

ll /sys/devices/bone_capemgr*
ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory

I load the image from here: 
http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz

What is my mistake?
Device tree compiler is up to date
device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+
20170719).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Found a lot of hints to use the 3.8 kernel. Think that one is already some 
years old, can't be true.

Question: How to create the required device tree overlay, because /sys/
devices/bone_capemgr* is not existing?

Thanks for help




-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4a0b610e-7cc7-4f97-8a93-0e956ae0412c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Linux RAM access

[jazzjohn]

Thank you Robert. Might be just what I need!

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/70a15ef1-af75-47a6-a542-919e3b8ae394%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Linux RAM access

[Robert Nelson]

On Thu, Aug 31, 2017 at 4:08 PM,   wrote:
> We need the PRU to sample 10MB of 8 bit data in one second and store the 
> bytes into RAM.
>
> Can the PRU do this?
>
> Any insight would be appreciated.

look at beaglelogic:

http://www.beaglelogic.net/

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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhY6zJ6fBsX2OLJ3VRSNfgrMhKgKmvcZA7WXwTtBOOocA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Linux RAM access

[jazzjohn]

We need the PRU to sample 10MB of 8 bit data in one second and store the bytes 
into RAM.

Can the PRU do this? 

Any insight would be appreciated.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9c0a1546-09ab-452e-9786-aa551b2726b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU speak fails to compile

[williamscaff . usp]

I did some modifications to the pru_speak.c to correct errors until it 
finally compiled.

Now the problem is that the directory /sys/class/misc/pru_speak/ is not 
created and the "build/bdist.linux-armv7l/egg/pru_speak/pruspeak.py", line 
20, in __init__ method fails with:

IOError: [Errno 2] No such file or directory: 
'/sys/class/misc/pru_speak/pru_speak_abort'

I don't know how to proceed from that. Some googling sugested a 
misc_register() call, but there are no miscdevice at all at the pru_speak.c.

Any help?

Em quarta-feira, 28 de junho de 2017 16:54:35 UTC-3, RobertCNelson escreveu:
>
> On Wed, Jun 28, 2017 at 2:52 PM, Robert Nelson  > wrote: 
> > On Wed, Jun 28, 2017 at 1:23 PM,   
> wrote: 
> >> Hello, 
> >> 
> >> I am trying to use the PRU from my beagleboard black for real time 
> control. 
> >> The PRU speak is great because it's the easiest way I could find for 
> using 
> >> the ADC PWM DIOs in real time. 
> >> 
> >> However, some things changed and the code doesn't compile anymore with 
> >> errors described in the github page here. 
> >> 
> >> Any help solving the compilation problem or suggesting another similar 
> >> library is very welcome. 
> > 
> > I believe pruspeak was tied to the v3.14.x-ti remoteproc 
> implementation.. 
> > 
> > void *rproc_da_to_va(struct rproc *rproc, u64 da, int len); 
> > 
> > 
> https://github.com/deepakkarki/pruspeak/blob/master/src/driver/pru_speak.c#L109
>  
> > 
> > Got defined in v4.4.x-ti as: 
> > 
> > void *rproc_da_to_va(struct rproc *rproc, u64 da, int len, u32 flags); 
>
> correction, this got first defined in v4.1.x-ti.. 
>
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5f7f4780-41ca-49a1-9bc2-c26f0666b186%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.