[beagleboard] Re: PRU does not start.

[dinuxbg]

Could you post the output of "dmesg | tail -40" so that we can see the 
other remoteproc related kernel messages?

Are you by any chance using pru-gcc? If yes, you would need to upgrade your 
kernel to 4.14.94-ti-r96 . If you are using clpru then you should be fine.

Regards,
Dimitar

On Sunday, March 10, 2019 at 6:27:40 PM UTC+2, gw wrote:
>
> 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/11689ce6-cf4a-4d81-94b4-008e740796f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RPMsg not working on PRU1

[dinuxbg]

Did you also update the interrupt map:

struct ch_map pru_intc_map[] = { {18, 3},
 {19, 1},
};



Did you check that your PRU1 core is actually running and can drive the 
LED? For example, toggle the LED without rpmsg with a simple loop and delay.

Regards,
Dimitar

On Wednesday, February 13, 2019 at 9:06:48 PM UTC+2, Jacek Radzikowski 
wrote:
>
> I did. I even ran examples provided by TI, and the one for PRU1 does not 
> work.
>
> Jacek.
>
>
> On Wed, Feb 13, 2019 at 1:30 PM > wrote:
>
>> Did you change the interrupt numbers?
>>
>> /* The PRU-ICSS system events used for RPMsg are defined in the Linux 
>> device tre
>> e 
>>  * PRU0 uses system event 16 (To ARM) and 17 (From ARM) 
>>  * PRU1 uses system event 18 (To ARM) and 19 (From ARM) 
>>  */ 
>> #define TO_ARM_HOST 18   
>> #define FROM_ARM_HOST   19
>>
>>
>>
>> Regards,
>> Dimitar
>>
>> On Wednesday, February 13, 2019 at 10:02:25 AM UTC+2, Jacek Radzikowski 
>> wrote:
>>>
>>> Hello,
>>>
>>> I have problems with receiving remoteproc messages on PRU1. The code 
>>> works fine when configured and executed on PRU0, but PRU1 never receives 
>>> any interrupts (event numbers set for each PRU accordingly).
>>> I modified examples PRU_RPMsg_Echo_Interrupt0 and 
>>> PRU_RPMsg_Echo_Interrupt1 to flip I/O pins with LEDs whenever interrupt 
>>> comes. 
>>> On PRU0 example works as expected. Each time a message comes, the LED 
>>> switches state. However, example for PRU1 behaves like it never receives 
>>> any interrupts from ARM host. In my application I'm using interrupts to 
>>> signal PRU1 from PRU0, and hey work fine.
>>> Has anybody been able to resolve this issue?
>>>
>>> I'm running kernel 4.14.94-ti-r93 on Debian Image 2019-01-27, with PRU 
>>> tools installed by ti-pru-cgt-installer  2.1.5-0rcnee1~stretch+20180514
>>>
>>> Regards,
>>> Jacek.
>>>
>>>
>>> -- 
>>> Given a choice between two theories, take the one which is funnier 
>>>
>> -- 
>> 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/9ade0464-7903-4a00-9885-4649b243c1b7%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Given a choice between two theories, take the one which is funnier 
>

-- 
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/07741e37-2dca-4c5d-8559-65c5f488b4b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RPMsg not working on PRU1

[dinuxbg]

Did you change the interrupt numbers?

/* The PRU-ICSS system events used for RPMsg are defined in the Linux 
device tre
e 
 * PRU0 uses system event 16 (To ARM) and 17 (From ARM) 
 * PRU1 uses system event 18 (To ARM) and 19 (From ARM) 
 */ 
#define TO_ARM_HOST 18   
#define FROM_ARM_HOST   19



Regards,
Dimitar

On Wednesday, February 13, 2019 at 10:02:25 AM UTC+2, Jacek Radzikowski 
wrote:
>
> Hello,
>
> I have problems with receiving remoteproc messages on PRU1. The code works 
> fine when configured and executed on PRU0, but PRU1 never receives any 
> interrupts (event numbers set for each PRU accordingly).
> I modified examples PRU_RPMsg_Echo_Interrupt0 and 
> PRU_RPMsg_Echo_Interrupt1 to flip I/O pins with LEDs whenever interrupt 
> comes. 
> On PRU0 example works as expected. Each time a message comes, the LED 
> switches state. However, example for PRU1 behaves like it never receives 
> any interrupts from ARM host. In my application I'm using interrupts to 
> signal PRU1 from PRU0, and hey work fine.
> Has anybody been able to resolve this issue?
>
> I'm running kernel 4.14.94-ti-r93 on Debian Image 2019-01-27, with PRU 
> tools installed by ti-pru-cgt-installer  2.1.5-0rcnee1~stretch+20180514
>
> Regards,
> Jacek.
>
>
> -- 
> Given a choice between two theories, take the one which is funnier 
>

-- 
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/9ade0464-7903-4a00-9885-4649b243c1b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Graphics emulation and building SGX drivers with Android

[dinuxbg]

Error comes from hw composer, which should have no relation to 3D 
acceleration. Can you point to the source for the hwcomposer module you are 
using? Do you have it listed in PRODUCT_PACKAGES ?

Which aosp version are you trying to bring up? Do you have 
/dev/graphics/fb* device?

Regards,
Dimitar

петък, 1 февруари 2019 г., 5:12:51 UTC+2, minde...@gmail.com написа:
>
> Hi,
>
>   I am struggling to get graphics working with Android. I do not have SGX 
> drivers and want to rely on software emulation and rendering. Does this 
> work with Android?
>
> I get the following errors during boot up:
>
>
> ---
> 01-01 00:00:10.753   123   123 D libEGL  : loaded 
> /system/lib/egl/libGLES_android.so
> 01-01 00:00:11.099   123   123 E SurfaceFlinger: hwcomposer module not 
> found
> 01-01 00:00:11.099   123   123 E SurfaceFlinger: ERROR: failed to open 
> framebuffer (No such file or directory), aborting
>
> ---
>
> Is using SGX the only way or I can somehow use only software rendering to 
> get by? If I can use software rendering how should I go about doing it?
>
> Thanks,
> Gautam.
>
>

-- 
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/185703dd-fdc2-4899-9977-b0ca6b3be9c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dinuxbg]

What does "systemd-analyze blame" return? 

On Tuesday, November 27, 2018 at 7:28:29 PM UTC+2, wi...@geomonkey.com 
wrote:
>
>
> 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/f90cf563-54e8-4d97-bd77-999b8bd46a4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [Announcement] New PRU GCC release

[dinuxbg]

Yes, you can build it for x86 or x86_64 hosts. Follow the build 
instructions from https://github.com/dinuxbg/gnupru/blob/master/README.md

събота, 21 април 2018 г., 22:48:21 UTC+3, Jay Kickliter написа:
>
> Is it possible to build pru-gcc as a cross-compiler to run on x86?
>
> On Tuesday, April 10, 2018 at 3:35:59 PM UTC-7, din...@gmail.com wrote:
>>
>> Hi,
>>
>> I'd like to announce the new Beta RC3 20180310 
>> <https://github.com/dinuxbg/gnupru/tree/2018.03-beta-rc3> release of the GCC 
>> PRU port <https://github.com/dinuxbg/gnupru>. It contains breaking 
>> changes that were necessary to improve ABI 
>> <https://en.wikipedia.org/wiki/Application_binary_interface> 
>> compatibility with the TI proprietary toolchain. 
>>
>> When you upgrade, please make sure to:
>>
>>- Clean your object files and rebuild your projects (make clean && 
>>make).
>>- Pass -mabi=ti to pru-gcc if you intend to link GCC and TI CGT 
>>object files. If you use pru-gcc exclusively, you don't need to pass this 
>>option.
>>
>>
>> Prebuilt debian stretch packages for armhf are available here for 
>> download:
>>
>> https://github.com/dinuxbg/gnupru/releases/download/2018.03-beta-rc3/binutils-pru_2.30.51.20180310_armhf.stretch.deb
>>
>> https://github.com/dinuxbg/gnupru/releases/download/2018.03-beta-rc3/gcc-pru_8.0.1.20180310_armhf.stretch.deb
>>
>> For more detailed documentation about ABI compatibility, you may read 
>> https://github.com/dinuxbg/gnupru/wiki/ABI .
>>
>> Feedback would be appreciated. Are the examples sufficient? Cryptic 
>> documentation? Missing features? I'd like to hear about it. Right now I'm 
>> working on cleaning up the patches so that I try to send them upstream to 
>> GNU.
>>
>> Regards,
>> Dimitar
>>
>>

-- 
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/d7de1b58-0c2f-4045-a1e4-37862e0b8b84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] [Announcement] New PRU GCC release

[dinuxbg]

Hi,

I'd like to announce the new Beta RC3 20180310 
<https://github.com/dinuxbg/gnupru/tree/2018.03-beta-rc3> release of the GCC 
PRU port <https://github.com/dinuxbg/gnupru>. It contains breaking changes 
that were necessary to improve ABI 
<https://en.wikipedia.org/wiki/Application_binary_interface> compatibility 
with the TI proprietary toolchain. 

When you upgrade, please make sure to:

   - Clean your object files and rebuild your projects (make clean && make).
   - Pass -mabi=ti to pru-gcc if you intend to link GCC and TI CGT object 
   files. If you use pru-gcc exclusively, you don't need to pass this option.


Prebuilt debian stretch packages for armhf are available here for download:
https://github.com/dinuxbg/gnupru/releases/download/2018.03-beta-rc3/binutils-pru_2.30.51.20180310_armhf.stretch.deb
https://github.com/dinuxbg/gnupru/releases/download/2018.03-beta-rc3/gcc-pru_8.0.1.20180310_armhf.stretch.deb

For more detailed documentation about ABI compatibility, you may read 
https://github.com/dinuxbg/gnupru/wiki/ABI .

Feedback would be appreciated. Are the examples sufficient? Cryptic 
documentation? Missing features? I'd like to hear about it. Right now I'm 
working on cleaning up the patches so that I try to send them upstream to 
GNU.

Regards,
Dimitar

-- 
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/1e3c1850-46ef-4184-91ee-a33311eae006%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: rproc bind/unbind problem

[dinuxbg]

Try:
sudo bash
echo 4a334000.pru0 > /sys/bus/platform/drivers/pru-rproc/unbind




On Monday, February 19, 2018 at 5:03:32 PM UTC+2, Filip Kotouček wrote:
>
> Hello everyone,
>
> I have a problem with rproc PRU driver in Linux. My setup is beaglebone 
> black and official debian 
> image bone-debian-9.3-iot-armhf-2018-01-28-4gb.img.xz.
>
> The problem is simple. I cannot find bind/unbind in the rproc driver. 
>
> Here is the console ouptup:
> prusa_pro:/# echo 4a334000.pru0 > 
> /sys/bus/platform/drivers/pru-rproc/unbind
> -sh: /sys/bus/platform/drivers/pru-rproc/unbind: Permission denied
>
> I'm kind of new in Linux so I guess I'm missing something simple. I tried 
> to load rpmsg firmware example from TI and it worked OK. But still no 
> bind/unbind in /sys/bus/platform/drivers/pru-rproc/.
>
> Thanks for any advice.
>

-- 
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/fa64a9cf-fea1-472b-a59f-d597847dd661%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU/DDR Feasibility

[dinuxbg]

DDR bandwidth will be sufficient. You should be worried about DDR read 
access latency. I think that in the worst case you may not be able to read 
data in time for the spi byte shift. I would suggest to dedicate one pru to 
copy from ddr into shared sram. Or check if hw spi can ne used in slave 
mode.

TI wiki had a table with typical cycles needed by pru for accessing ddr and 
sram.

Regards,
Dimitar

понеделник, 22 януари 2018 г., 18:58:17 UTC+2, David Edwards написа:
>
> I'm also reading that allocating more than 8MB of the external RAM may be 
> an issue.  Looks like I might need the core after all to facilitate an 
> intermediary ring buffer to the full 30MB of memory is user space
>

-- 
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/ef29a7e1-59a5-4a05-b695-4e6f7c737ca0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Kernel 4.9.45 - remoteproc - PRU shared Memory

[dinuxbg]

Hi,

Are you sure it is the driver and not the PRU firmware?

Remoteproc host driver will load the PRU memories with contents from the 
ELF file.

If you have declared your shared buffer as "static char mybuffer[1024]", 
then the compiler will allocate 1024 bytes into the BSS section, and the 
PRU firmware init (CRT library) will set it to zero on startup. You may try 
putting the array into ".noinit" section. Another thing to try is declaring 
"static char *mybuffer = (char *)0x1000;", and ensuring that linker will 
not put any variables into the 12KB Shared DMEM.

Regards,
Dimitar

On Saturday, January 20, 2018 at 12:47:09 PM UTC+2, Maxim Oberkoch wrote:
>
> Hi folks,
>
> right now I am trying to get the the PRU with the remoteproc-driver run. 
> It ist working quite well, but there is one Problem which I dont now how to 
> solve it.
>
> I am trying to use the shared Memory between the ARM and PRU. 4a31 
> startig adress. My Problem is that in my application I want to write data 
> to the shared memory and afterward start the PRU-Core and read put the 
> data. I am writing with a c-Programm with mmap. It works good and I can 
> read out the data after I wrote it to the RAM. I am using the devmem2 -tool 
> from Derick´s Exploring Beaglebone Book.
>
> No my main problem. After I wrote my data to the shared RAM and start the 
> PRU-Core (changing the state of the remoteproc-driver) all my data is gone 
> and in the shared Memory just zeros exist. My question is, why is the 
> driver writing just zeros to the shared memory when starting the PRU-Core. 
> And is the any possibility to avoid this process of initilaizing all the 
> shared memory?
>
> Do you have any ideas? Why and how this happens?
>
>
> Best Wishes
>
> Maxim
>

-- 
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/397f8013-3d91-4e06-829c-a14789c5b712%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Help resetting signal to reuse prussdrv_pru_send_event(ARM_PRU0_INTERRUPT);

[dinuxbg]

Hi,

I'm not sure if you can clear the interrupt flag by writing to R31. You may 
check the TI RPMSG examples which also rely on interrupts: 
https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/labs/lab_5/solution/PRU_RPMsg_Echo_Interrupt1/main.c#line85

Check the initialization, but also note how they clear the flag:
/* Check bit 30 of register R31 to see if the ARM has kicked us */
if (__R31 & HOST_INT) {
/* Clear the event status */
CT_INTC.SICR_bit.STS_CLR_IDX = FROM_ARM_HOST;



Regards,
Dimitar

On Saturday, December 2, 2017 at 7:02:54 AM UTC+2, Joseph Foster wrote:
>
>
> I'm trying to reuse the prussdrv_pru_send_event(ARM_PRU0_INTERRUPT); 
> function, but I can't reset the register for WBS r31,30
>
> This is my PRU code:
> Enter code here...// Origin 0 defines the start of the program in the
> // PRU's instruction RAM, entrypoint is for debugging
> #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   0x00012000
>
>
>
>
> .origin 0 // offset of the start of the code in PRU memory
> .entrypoint START // program entry point, used by debugger only
>
> #define PRU0_R31_VEC_VALID (1<<5)
> #define SIGNUM 3 // corresponds to PRU_EVTOUT_0
>
>
> START:
> // initialize loop counter
> WBS r31,30 //Wait for signal
> MOV R16, SHARED_RAM
> lbbo r1,r16,0,8
> add r3,r1,r2
> sbbo R3, R16, 8, 4
> MOV r15,30
> clr r31,r15
> WBS r31,30 //Wait for signal
> MOV R31.b0, PRU0_R31_VEC_VALID | SIGNUM
> HALT
>
> And this is the c:
> Enter code here...#include 
> #include 
> #include 
> #include 
> #include 
>
> #define PRU_SHARED_MEM_ADDR 0x00012000
> #define SHM_OFFSET 2048
>
> static int pru_cleanup(void) {
>int rtn = 0;
>
>/* clear the event (if asserted) */
>if(prussdrv_pru_clear_event(PRU_EVTOUT_0, PRU0_ARM_INTERRUPT)) {
>   fprintf(stderr, "prussdrv_pru_clear_event() failed\n");
>   rtn = -1;
>}
>
>/* halt and disable the PRU (if running) */
>if((rtn = prussdrv_pru_disable(0)) != 0) {
>   fprintf(stderr, "prussdrv_pru_disable() failed\n");
>   rtn = -1;
>}
>
>/* release the PRU clocks and disable prussdrv module */
>if((rtn = prussdrv_exit()) != 0) {
>   fprintf(stderr, "prussdrv_exit() failed\n");
>   rtn = -1;
>}
>
>return rtn;
> }
>
> static int pru_setup(const char * const path) {
>int rtn;
>tpruss_intc_initdata intc = PRUSS_INTC_INITDATA;
>
>if(!path) {
>   fprintf(stderr, "pru_setup(): path is NULL\n");
>   return -1;
>}
>
>/* initialize PRU */
>if((rtn = prussdrv_init()) != 0) {
>   fprintf(stderr, "prussdrv_init() failed\n");
>   return rtn;
>}
>
>/* open the interrupt */
>if((rtn = prussdrv_open(PRU_EVTOUT_0)) != 0) {
>   fprintf(stderr, "prussdrv_open() failed\n");
>   return rtn;
>}
>
>/* initialize interrupt */
>if((rtn = prussdrv_pruintc_init()) != 0) {
>   fprintf(stderr, "prussdrv_pruintc_init() failed\n");
>   return rtn;
>}
>
>/* load and run the PRU program */
>if((rtn = prussdrv_exec_program(0, path)) < 0) {
>   fprintf(stderr, "prussdrv_exec_program() failed\n");
>   return rtn;
>}
>
>return rtn;
> }
>
> volatile int32_t* init_prumem()
> {
> volatile int32_t* p;
> prussdrv_map_prumem(PRUSS0_SHARED_DATARAM, (void**));
> return p+SHM_OFFSET;
> }
>
> int main()
> {
> printf("Init PRU..\n");
> int ret = pru_setup("PRUTest.bin");
> if(ret == -1) return -1;
> volatile int* shared_mem = init_prumem();
> //usleep(100);
> printf("Waiting for message...\n");
> shared_mem[0] = 5;
> shared_mem[1] = 10;
> prussdrv_pru_send_event(ARM_PRU0_INTERRUPT);
> int n = prussdrv_pru_wait_event(PRU_EVTOUT_0);
> printf("Pru ended. Event: %i\n", n);
> printf("Got number %d\n", shared_mem[2]);
> pru_cleanup();
> return 0;
> }
>
> In this example, the c code should never exit because the PRU code should 
> be waiting for a second signal, but it does exit. How do I reset the signal 
> so that I can reuse the interrupt?
>
>

-- 
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/3c97ab34-a53d-4e25-87ac-e8d2891aab4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Linux Kernel tree for porting to mailine and basic support.

[dinuxbg]

Hi,

I think https://github.com/beagleboard/linux would be the best reference 
tree.

Which subsystem are you going to mainline? 

Regards,
Dimitar

On Sunday, November 26, 2017 at 6:01:52 AM UTC+2, minde...@gmail.com wrote:
>
> Hi,
>
> What is the Linux kernel tree which is used to provide mainline support 
> for the beaglebone black? I would like to contribute towards mainlining and 
> I would like to know which is the tree for which the beaglebone black 
> development happens.
>
> I am assuming the tree is  https://github.com/beagleboard/linux 
> .
>  
> Please correct me if I am wrong.
>
> Thanks in advance,
> Gautam.
>

-- 
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/5ee68c6f-db9e-49e7-812e-054c0fe800f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBone Black Boot optimization

[dinuxbg]

Could you post your dmesg log?

On Wednesday, November 15, 2017 at 10:51:29 AM UTC+2, Alexander Rössler 
wrote:
>
> Hello everyone,
>
> I'm using the latest IoT images for the BBB and noticed that the bootup 
> time from the eMMC is very slow. it takes ~1.5min for the USB gadget 
> network interface to appear under Linux.
>
> What can I do to improve the startup performance of the BBB?
>
> So far I have disabled auto for the eth0 interface.
>
> sudo nano /etc/network/interfaces
> allow-hotplug eth0
>
>
> Moreover, I have disabled graphical boot.
>
> systemctl set-default multi-user.target
>> systemctl get-default
>
>
>  Still very slow is the generic-board-startup.service
>
> 1min 53.980s dev-mmcblk1p1.device
>1min 50.627s generic-board-startup.service
>  4.208s ModemManager.service
>  4.106s systemd-udev-trigger.service
>  2.366s networking.service
>  2.032s NetworkManager.service
>  1.973s capemgr.service
>  1.838s systemd-journald.service
>  1.809s pppd-dns.service
>  1.579s dnsmasq.service
>  1.486s rsyslog.service
>  1.098s avahi-daemon.service
>   920ms systemd-logind.service
>   856ms systemd-udevd.service
>   845ms bb-wl18xx-wlan0.service
>   737ms sys-fs-fuse-connections.mount
>   730ms ssh.service
>   724ms systemd-sysctl.service
>   719ms systemd-timesyncd.service
>   651ms sys-kernel-debug.mount
>   604ms systemd-update-utmp.service
>   592ms dev-mqueue.mount
>   559ms sys-kernel-config.mount
>   493ms systemd-remount-fs.service
>   458ms polkit.service
>   448ms systemd-user-sessions.service
>   414ms systemd-tmpfiles-setup-dev.service
>   413ms systemd-tmpfiles-setup.service
>   360ms systemd-random-seed.service
>   359ms systemd-journal-flush.service
>   319ms systemd-modules-load.service
>   319ms kmod-static-nodes.service
>   225ms systemd-update-utmp-runlevel.service
>   168ms bb-wl18xx-bluetooth.service
>
>
>  I noticed that SSH key regeneration takes ~15s at boot. However, when I 
> removed /etc/ssh/ssh.regenerate USB networking did not work anymore.
>
> What else can I do to make the BBB boot faster?
>

-- 
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/f9d92539-d074-4e60-bfe1-c09532bd1968%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Best way for events between PRU and processor?

[dinuxbg]

Hi,

FYI, recent remoteproc RPMSG versions have moved from mailboxes to 
interrupts for 
communication: 
https://git.ti.com/pru-software-support-package/pru-software-support-package/commit/69805828df0f262fb60363c2db189d1b8d0b693c

A race-free algorithm would require the interrupts simply to wake the peer, 
and rely on shared memory FIFO for handling events. AFAIK, that's the idea 
used by virtio/RPMSG. In pseudo-code:

1. Wait for interrupt.
2. Clear interrupt.
3. Drain the events-FIFO located in shared memory.

Regards,
Dimitar

On Tuesday, November 7, 2017 at 4:09:33 AM UTC+2, Ken Shirriff wrote:
>
> I'm trying to send information back and forth between the processor and 
> the PRU, and I'm looking for suggestions on the best way to do this.
>
> Currently I'm using PRU_EVTOUT0 to send events from the PRU. The processor 
> code does a select() on the PRU_EVTOUT_0 fd to find out when an event has 
> happened. Then I do a prussdrv_pru_wait_event() and 
> prussdrv_pru_clear_event() to get rid of the event. (The select is because 
> I also want to wait for network data.)
>
> However, this is kind of a mess of race conditions, since an event can 
> come in between the select and the clear. Or two events can happen before 
> the select. So I have various status flags that the PRU sets in memory. But 
> that leads to other race conditions.
>
> So, I'm wondering if there's a better way to handle events back and forth. 
> Other people must have dealt with this and come up with good solutions.
>
> I've seen stuff about Remoteproc - is that the cool new technology? Its 
> mailboxes seem like a good model. However, I'd rather stick with the UIO 
> model instead of moving to a new kernel and rewriting everything if 
> possible. 
>
> My application, in case it's relevant: I'm building a network gateway with 
> the PRU bit-banging a 3 megabit/second Ethernet. So the processor sends 
> packets to the PRU to transmit, and the PRU tells the processor about 
> incoming packets. The PRU needs to tell the processor when a send is 
> completed, or when a packet has arrived. 
>
> Thanks for any help,
> Ken
>

-- 
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/1d770722-5d3e-4be2-89e3-5e0385cc03d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU and CPU driven by different oscillators?

[dinuxbg]

You may find this tool from TI 
useful: http://processors.wiki.ti.com/index.php/AM335x_Clock_Tree_Tool

On Saturday, April 29, 2017 at 10:14:31 PM UTC+3, Justin Pearson wrote:
>
> Thanks Graham. What do you mean by "check and verify the clock tree 
> behavior"? I searched the TRM for "clock tree" but I'm still not sure how 
> to figure out which timers make their way through various PLLs to the PRU 
> and main CPU. 
>
>
>
> On Wed, Apr 26, 2017 at 10:00 AM, Graham  > wrote:
>
>> Well, best way is to read the schematic. (BBB Rev C schematic, dated 
>> March 21, 2014)
>> 24 MHz Sitara clock crystal is on upper left of page 3, hooked to main 
>> oscillator I/O.
>> There is also a 32 kHz crystal shown there for the Real Time Clock.
>>
>> The 25 MHz crystal is on page 9, hooked to the LAN8710, which is the 
>> Ethernet PHI.
>>
>> I am not a PRU expert, but I don't think there is, or should be, a fixed 
>> relationship between
>> the PRU clock and the CPU clock.  The CPU in a Sitara is a variable speed 
>> CPU, and 
>> can run anywhere from a few hundred MHz to a GHz, depending on loading,
>> and it is under kernel control.
>>
>> I would not think you would want the 200 MHz clock for the PRU to be 
>> variable
>> like that, since it would totally destroy the real time advantage of the 
>> PRU.
>>
>> So, I suspect that the clock for the PRU is a fixed clock coming from a 
>> different
>> place in the clock tree than the variable speed CPU.
>>
>> You should really check and verify the clock tree behavior.
>>
>> --- Graham
>>
>> ==
>>
>> On Wednesday, April 26, 2017 at 8:02:38 AM UTC-5, Justin Pearson wrote:
>>>
>>> Thanks Graham. Follow-up questions: 
>>>
>>> 1. Where exactly did you find this information? I looked through the TRM 
>>> and SRM but couldn't find anything definitive.
>>>
>>> 2. Is the 200-MHz PRU driven from the same 24 MHz oscillator that drives 
>>> the CPU? If so, is it correct that the PRU cycle counter increments 
>>> precisely once for every 5 CPU cycles? 
>>>
>>> Thanks for your help.
>>> -Justin
>>>
>>> On Tuesday, April 25, 2017 at 7:35:19 PM UTC-7, Graham wrote:

 The CPU in a BBB runs from a 24 MHz Oscillator.
 There is a 25 MHz oscillator on the board, but that is for the Ethernet.
 --- Graham

 ==

 On Tuesday, April 25, 2017 at 7:09:50 PM UTC-5, Justin Pearson wrote:
>
> How can I find out whether the PRU and CPU are driven by the same 
> oscillator? Specifically, a colleague told me that the IEP timer (which 
> I'm 
> reading with the PRU) is driven by a 24 MHz oscillator that's PLL'd so 
> the 
> timer increments at 200 MHz, whereas the CPU is driven by a 25 MHz 
> oscillator PLL'd so that the CPU runs at 1 GHz.
>
> It seems to me that if they're driven by different oscillators, then 
> they could drift apart over time. 
>
> Page 1177 of the TRM (spruh73n.pdf) mentions a 32-kHz crystal 
> oscillator, but I don't see how that's related.
>
> Also, are these oscillators within the Sitara SoC, or somewhere else 
> on the BBB? The SRM just references 24.576 MHz oscillator (pg 70 of e14 
> BBB_SRM_rev 0.9.pdf), and I'm not sure how that's related to the 24/25 
> MHz 
> oscillators my colleague mentioned.
>
> Thanks for your help.
>
> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/XFv4Ha4RbD4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/843f0f74-584e-440d-828f-df0cd61d1e1b%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/5c7e6721-1075-4d6e-a69e-bc38f3409592%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Are the am335x_pru_package examples incorrectly (dangerously) accessing DDR memory?

[dinuxbg]

Per arch/arm/kernel/head.S, 0x80004000 or 0x80003000 is where the MMU page 
directory table is stored. I could not trace who uses the lower addresses. 
Nevertheless, I wouldn't hardcode my PRU to write there :)

I do not see DT bindings for extram_pool_sz in Beagleboard v4.4 kernel.

Regards,
Dimitar

On Tuesday, March 14, 2017 at 9:12:44 PM UTC+2, ags wrote:
>
> Very useful response. At the least it verifies that my conclusions are not 
> totally unfounded. I suppose it could be just dumb luck that it works at 
> all - but I also wonder if there's not something that kernel gurus know 
> about what the first  pages of memory are used for, and the author took 
> advantage of that. I also see that on my system, kernel code starts at 
> 0x08000_8000. Still not a good practice though IMO.
>
> I'm wondering if there isn't some way to use the DT to not only enable the 
> PRUSS, but also select a driver, and configure the driver parameters (e.g. 
> "extram_pool_sz") automatically. I read that the remoteproc and uio drivers 
> conflict, so none is loaded by default. I suppose it would require a change 
> to the pruss driver (whatever reads the "ti,pruss-v2" entry in the device 
> tree) to support this, but it would be convenient.
>
> Thanks.
>
> On Friday, March 10, 2017 at 11:52:42 AM UTC-8, din...@gmail.com wrote:
>>
>> Hi,
>>
>> I believe the example is indeed buggy, and works by accident. You can 
>> check "cat /proc/iomem" and see that your mapped region overlaps the 
>> kernel code.
>>
>> If you need to properly allocate and map DDR between ARM and PRU, then I 
>> would suggest to:
>>
>>1. Load PRU UIO with "modprobe uio_pruss extram_pool_sz=2097152" in 
>>order to tell it allocate contiguous memory.
>>2. Use prussdrv_map_extmem() from ARM side to map the allocated DDR 
>>chunk. Example 
>>
>> <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L294>
>>3. Get the physical DDR base address of the chunk by using 
>>prussdrv_get_phys_addr(). Example 
>>
>> <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L297>
>>4. Write the physical DDR base address to a pre-defined location in 
>>PRU DRAM. If you are using pasm, then just hard-code the pre-defined 
>>location. If your firmware is in ELF format, there is a bit nicer way 
>>
>> <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L207>
>>.
>>
>>
>> Regards,
>> Dimitar
>>
>> On Tuesday, March 7, 2017 at 10:07:31 PM UTC+2, ags wrote:
>>>
>>> I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 
>>> using just the uio_pruss (& uio) drivers, without any of the prussdrv code. 
>>> Big milestone in my project.
>>>
>>> A long time ago I asked a question about the examples in the pru here: 
>>> https://groups.google.com/d/topic/beagleboard/Kv03QMsgOmo/discussion
>>>
>>> as did someone else here: 
>>> https://groups.google.com/d/topic/beagleboard/vnZ9eSzoo6Y/discussion
>>>
>>> but I found no answer to help me. From a thorough review of the examples 
>>> in the am335x_pru_package (using the prussdrv uio-based pru driver) here: 
>>> https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c
>>>
>>> it *appears* to me that this example (to teach/illustrate proper use of 
>>> pru in the BB family) works only by luck - or taking advantage of some bit 
>>> of information that is undocumented (from my research).
>>>
>>> Specifically, when using the L3 DDR (main) memory to share data between 
>>> the A8 and PRU, it seems that rather than using the 256KiB size region 
>>> starting at 0x9c94_ (on my BBB rev C) it seems to simply hardcode 
>>> 0x8000_ and write away. See here:
>>>
>>> static int LOCAL_exampleInit () {
>>>  void *DDR_regaddr;
>>>  /* open the device */
>>>  mem_fd = open("/dev/mem", O_RDWR);
>>>  if (mem_fd < 0) {
>>>   printf("Failed to open /dev/mem (%s)\n", strerror(errno));
>>>   return -1;
>>>  }
>>>  /* map the memory */
>>>  ddrMem = mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, mem_fd
>>> , DDR_BASEADDR);
>>>  if (ddrMem == NULL) {
>>>   printf("Failed to map the device (%s)\n", strerror(errno));
>>>   close(mem_fd);
>>> 

[beagleboard] Re: Are the am335x_pru_package examples incorrectly (dangerously) accessing DDR memory?

[dinuxbg]

Hi,

I believe the example is indeed buggy, and works by accident. You can check 
"cat /proc/iomem" and see that your mapped region overlaps the kernel code.

If you need to properly allocate and map DDR between ARM and PRU, then I 
would suggest to:

   1. Load PRU UIO with "modprobe uio_pruss extram_pool_sz=2097152" in 
   order to tell it allocate contiguous memory.
   2. Use prussdrv_map_extmem() from ARM side to map the allocated DDR 
   chunk. Example 
   
<https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L294>
   3. Get the physical DDR base address of the chunk by using 
   prussdrv_get_phys_addr(). Example 
   
<https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L297>
   4. Write the physical DDR base address to a pre-defined location in PRU 
   DRAM. If you are using pasm, then just hard-code the pre-defined location. 
   If your firmware is in ELF format, there is a bit nicer way 
   
<https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L207>
   .


Regards,
Dimitar

On Tuesday, March 7, 2017 at 10:07:31 PM UTC+2, ags wrote:
>
> I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 
> using just the uio_pruss (& uio) drivers, without any of the prussdrv code. 
> Big milestone in my project.
>
> A long time ago I asked a question about the examples in the pru here: 
> https://groups.google.com/d/topic/beagleboard/Kv03QMsgOmo/discussion
>
> as did someone else here: 
> https://groups.google.com/d/topic/beagleboard/vnZ9eSzoo6Y/discussion
>
> but I found no answer to help me. From a thorough review of the examples 
> in the am335x_pru_package (using the prussdrv uio-based pru driver) here: 
> https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c
>
> it *appears* to me that this example (to teach/illustrate proper use of 
> pru in the BB family) works only by luck - or taking advantage of some bit 
> of information that is undocumented (from my research).
>
> Specifically, when using the L3 DDR (main) memory to share data between 
> the A8 and PRU, it seems that rather than using the 256KiB size region 
> starting at 0x9c94_ (on my BBB rev C) it seems to simply hardcode 
> 0x8000_ and write away. See here:
>
> static int LOCAL_exampleInit () {
>  void *DDR_regaddr;
>  /* open the device */
>  mem_fd = open("/dev/mem", O_RDWR);
>  if (mem_fd < 0) {
>   printf("Failed to open /dev/mem (%s)\n", strerror(errno));
>   return -1;
>  }
>  /* map the memory */
>  ddrMem = mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, mem_fd, 
> DDR_BASEADDR);
>  if (ddrMem == NULL) {
>   printf("Failed to map the device (%s)\n", strerror(errno));
>   close(mem_fd);
>   return -1;
>  }
>  //FLush the flag locations of PRU0 and PRU1
>  DDR_regaddr = ddrMem;
>  *(unsigned long*) DDR_regaddr = 0x00;
>  DDR_regaddr = ddrMem + 0x4;
>  *(unsigned long*) DDR_regaddr = 0x00;
>  return(0);
> }
> I can understand how this might work "by accident" if these first eight 
> bytes in DDR are not used. But that's not a good example. Questions: 1) Is 
> there some "magic" to this physical memory location that I'm missing out 
> on? Or am I mis-reading the code, and it is *not* just writing to physical 
> memory 0x0-0x7? 2) Is it correct that the actual DDR physical memory region 
> that is allocated by the uio driver is properly determined by examining 
> /sys/class/uio/uio/maps/map1/{addr,size}? If not, how? I think this is 
> useful information that would be helpful to others if provided. Perhaps 
> even an update to the example, if my assertions are correct.
>

-- 
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/db46432f-1830-4e5e-a4fe-a7671d0f74f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Issue with PRU cape LED hello world program

[dinuxbg]

Hi,

If you use PRU's "r30", then you need to mux your pin to "pruout" mode. The 
"gpio" mode is for the "classic" slow GPIOs that are accessed through the 
L3 bus.

I haven't tested, but you may want to try the following command:
 $ config-pin P9.28 pruout

Regards,
Dimitar

On Monday, February 27, 2017 at 1:03:27 AM UTC+2, Geoffrey Messier wrote:
>
> Hi everyone,
>
> I'm a beaglebone/PRU newbie and I'm stuck on getting a basic hello world 
> program up and running on the PRU.  My goal is to use load a simple PRU 
> assembly program to light an LED on the PRU development cape.  The light 
> corresponds to pin P9.28.  I'm using the uio_pruss kernel module.
>
> Rather than using an overlay, I'm opting to use config-pin since my 
> application will eventually require a fair bit of dynamic pin 
> reconfiguration.  I note in this post 
> 
>  that 
> the PRU is disabled in the default overlay.  Using the method suggested in 
> the post, I modify the default overlay I'm using 
> (am335x-boneblack-emmc-overlay.dtb) to change the status of the 
> pruss@4a30 fragment from "disabled" to "okay".  To make sure that my 
> board is now using my modified overlay, I've also disabled the heartbeat 
> LED.  When I reboot, the heartbeat flash is gone and when I use dtc -I fs 
> /sys/firmware/devicetree/base to look at the current device tree, the 
> fragment is as follows:
>
>pruss@4a30 {
> compatible = "ti,pruss-v2";
> ti,pintc-offset = <0x2>;
> ti,hwmods = "pruss";
> ti,deassert-hard-reset = "pruss", "pruss";
> status = "okay";
> interrupt-parent = <0x1>;
> interrupts = <0x14 0x15 0x16 0x17 0x18 0x19 0x1a 
> 0x1b>;
> phandle = <0xa5>;
> reg = <0x4a30 0x8>;
> linux,phandle = <0xa5>;
> };
>
>
> The cape seems to be working fine since "config-pin P9.28 hi" and 
> "config-pin P9.28 low" turns the LED on an off.
>
> My PRU assembly code, lighton.p, is:
> .origin 0 
> .entrypoint start 
>
> start:
> rept:
> set r30.t3
> jmp rept
> halt
>
> and my app loader code, loader.c, is:
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #define PRU_NUM 0 
>
> static int pru_cleanup(void) {
>int rtn = 0;
>
>if((rtn = prussdrv_pru_disable(PRU_NUM)) != 0) {
>   fprintf(stderr, "prussdrv_pru_disable() failed\n");
>   rtn = -1;
>}
>
>if((rtn = prussdrv_exit()) != 0) {
>   fprintf(stderr, "prussdrv_exit() failed\n");
>   rtn = -1;
>}
>
>return rtn;
> }
>
> int main(int argc, char **argv) {
>int rtn;
>
>if((rtn = prussdrv_init()) != 0) {
>   fprintf(stderr, "prussdrv_init() failed\n");
>   pru_cleanup();
>   return rtn;
>}
>
>if((rtn = prussdrv_open ( PRU_EVTOUT_0 )) != 0) {
>  fprintf(stderr,"prussdrv_open() failed\n");
>  pru_cleanup();
>  return rtn;
>}
>
>if((rtn = prussdrv_exec_program(PRU_NUM, "./lighton.bin")) < 0) {
>  fprintf(stderr, "prussdrv_exec_program() failed\n");
>  pru_cleanup();
>  return rtn;
>}
>
>   getchar();  /* Pause to let the program execute. */
>
>   return pru_cleanup();
> }
>
> The following is a screen capture of what I'm doing to try and get all of 
> this to run:
> root@beaglebone:~/pru-helloworld# uname -r
> 4.9.11-bone4
> root@beaglebone:~/pru-helloworld# lsmod
> Module  Size  Used by
> spidev  7466  0 
> c_can_platform  6486  0 
> c_can   9942  1 c_can_platform
> can_dev12174  1 c_can
> pwm_tiehrpwm4920  0 
> spi_omap2_mcspi10167  0 
> pwm_tiecap  3801  0 
> tieqep  7575  0 
> omap_aes   13012  0 
> omap_sham  21488  0 
> crypto_engine   5939  1 omap_aes
> uio_pruss   4928  0 
> omap_rng4572  0 
> rng_core7340  1 omap_rng
> evdev  10035  1 
> tps65217_charger4723  0 
> omap_wdt4159  0 
> leds_gpio   3308  0 
> uio_pdrv_genirq 3437  0 
> uio 8614  2 uio_pruss,uio_pdrv_genirq
> cpufreq_dt  4805  0 
> 8021q  18006  0 
> garp5788  1 8021q
> mrp 7092  1 8021q
> stp 2117  1 garp
> llc 5021  2 garp,stp
> cpufreq_powersave   1567  0 
> cpufreq_conservative 3649  0 
> root@beaglebone:~/pru-helloworld# ls /dev/ui*
> /dev/uinput  /dev/uio0  /dev/uio1  /dev/uio2  /dev/uio3  /dev/uio4 
>  /dev/uio5  /dev/uio6  /dev/uio7
> root@beaglebone:~/pru-helloworld# 

Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram

[dinuxbg]

Unfortunately I have not dealt with python for Pru.

On Tuesday, November 29, 2016 at 1:18:50 AM UTC+2, Neil Jubinville wrote:
> Thx, correct on many accounts.  I found it strange that there was no default 
> way load in a 32 bit value given it is the default register size.  
> 
> 
> Love the macro!  I am going to adopt it :)
> 
> 
> I'll likely now dig into the next level up which implementing the same in 
> pru-gcc / c code vs assembly.   Going even higher level , do you know if 
> there are core bindings to the pruMemMap in python?  I know PRU Speak works a 
> bit but not sure if it does the memory mapping parts.
> 
> 
> Neil
> 
> 
> 
> 
> 
> 
> On Monday, November 28, 2016 at 10:25:57 AM UTC-7, din...@gmail.com wrote:
> Hi Neil,
> 
> 
>  The "r2 = 20" syntax does not load a value in a register. It is for 
> setting symbols - see 
> https://sourceware.org/binutils/docs/as/Setting-Symbols.html#Setting-Symbols 
> . You probably meant to load r2 with a constant integer:
> 
> 
> 
>     ldi r2, %lo(20)
>      ldi, r2.w0 %hi_rlz(20)
> 
> 
> 
> 
> The %lo(X) returns the lower 16 bits of a 32-bit constant integer. The 
> "%hi_rlz(X) returns the higher 16-bits of a 32-bit integer, and marks the 
> instruction for possible elimination if those higher bits are all zero. You 
> may want to declare and use the following helper macro:
> 
> 
> .macro ldi32 rx, expr
>         ldi     \rx, %lo(\expr)
>         ldi     \rx\().w2, %hi_rlz(\expr)
> .endm
> 
>         ; Use like this:
>         ldi32   r2, 20
> 
> 
> 
> 
> Please note that "sp" (Stack Pointer) is an alias for "r2", and "ra" (Return 
> Address) is an alias for "r3". Hence R3 is used whenever you use the "call" 
> instruction to store the return PC address.
> 
> 
> I also don't think that "lbbo r2, r2, 0 4" is correct. You are overwriting 
> the R2 address with a value, which value you are using as an address in the 
> next iteration. Equivalent C code:
> 
> 
> 
>     uint32_t *r2;
>      r2 = (uint32_t)(*r2);
> 
> 
> Also, $lo(r6/4) is probably not what you meant. %lo expects a constant 
> integer as an argument. If you want to copy a register, simply use mov:
> 
> 
>  mov r2,r6
> 
> Regards,
> Dimitar
> 
> 
> On Monday, November 28, 2016 at 7:39:38 AM UTC+2, Neil Jubinville wrote:
> Ok I got it working,   the part I changed is commented out.
> 
> 
> Essentially I used my r6 debug register that had the correct one in it.  Now 
> I can dial in the blinky action! fun!
> 
> 
> So for some reason even though we were setting the r2 form the lbbo it just 
> did not like this syntax.
> 
> 
> 
>   ldi r14, %lo( r6/4 )
>   ldi r14.w2, %hi_rlz(r6/4)
> 
> 
> Seemed to always load the old initial value.   I have to search for the %lo 
> and %hi_rlz  meaning I know it is used to load a high and low set of bytes 
> due to limitations of ldi to a max of 65535 but it was probably messing 
> things up.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>         lbbo r2, r0, 8 ,4
>         mov r6, r2   // to prove in the c program that data arrived and is 
> correct when displayed R2 should equal R6- debug
> 
> 
>         sbbo  r0, r0, 0 , 48    // copy all 12 registers to memory R0...R11 .
> 
> 
>         // the goal is for  R2 to get  set in a C program outside theis 
> assembly.   Thus changing the speed of the
>        // blinking LED  - defualt is set to 1 second  = 200,000,000 cycles in 
> CPU delay.
> 
> 
>         // led on
>         mov     r30, r1
>         mov     r14,r6
>         call    delay_n2_cycles
> 
> 
>         // led off
>         mov     r30, r0
>         mov     r14, r6
>         call    delay_n2_cycles
> 
> 
> /*
>         // led on
>  mov     r30, r1
>  ldi r14, %lo( r6/4 )
>  ldi r14.w2, %hi_rlz(r6/4)
>  call delay_n2_cycles
> 
> 
>  // led off
>  mov r30, r0
>  ldi r14, %lo(r6/4)
>  ldi r14.w2, %hi_rlz(r6/4 )
>  call delay_n2_cycles
> */
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sunday, November 27, 2016 at 10:09:55 PM UTC-7, Neil Jubinville wrote:
> Yes, thank-you, I already know the prompt cycle needs to run twice to pick up 
> the write in the subsequent read cycle, no big deal there, I just enter the 
> same vale twice and I get the feedback. 
> 
> 
> The part I am focused on is why the value from the LBBO does not seem to be 
> used in the delay call.
> 
> 
> You may have missed my  last post where the LBBO worked using the 8 bytes of 
> offset,  R2 is the third 32 bit number in my reference   R0 is the first , R1 
> the second, R2 the third
> 
> 
>   lbbo    r2, r0, 8 ,4    works like a champ.
> 
> 
> 
> After the lbbo I transfer the value I entered into R6 in the PRU and it comes 
> back to me in the sbbo so I know it is working and getting to the general 
> registers.
> 
> 
> The question now is why R2 used as a delay value does not change the delay 
> time when it is truly reaching the PRU.
> 
> 
> Any comments on the initialization of R2 = 200,000,000 ?  does that syntax 
> lock it into a constant?
> 
> 
> 
> 
> 
> 
> 
> On Sunday, 

Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram

[dinuxbg]

Hi Neil,

 The "r2 = 20" syntax does *not* load a value in a register. It is for 
setting symbols - see 
https://sourceware.org/binutils/docs/as/Setting-Symbols.html#Setting-Symbols 
. You probably meant to load r2 with a constant integer:
ldi r2, %lo(20)
ldi, r2.w0 %hi_rlz(20)



The %lo(X) returns the lower 16 bits of a 32-bit constant integer. The 
"%hi_rlz(X) returns the higher 16-bits of a 32-bit integer, and marks the 
instruction for possible elimination if those higher bits are all zero. You 
may want to declare and use the following helper macro:
.macro ldi32 rx, expr
ldi \rx, %lo(\expr)
ldi \rx\().w2, %hi_rlz(\expr)
.endm

; Use like this:
ldi32   r2, 20


Please note that "sp" (Stack Pointer) is an alias for "r2", and "ra" 
(Return Address) is an alias for "r3". Hence R3 is used whenever you use 
the "call" instruction to store the return PC address.

I also don't think that "lbbo r2, r2, 0 4" is correct. You are overwriting 
the R2 address with a value, which value you are using as an address in the 
next iteration. Equivalent C code:
uint32_t *r2;
r2 = (uint32_t)(*r2);


Also, $lo(r6/4) is probably not what you meant. %lo expects a constant 
integer as an argument. If you want to copy a register, simply use mov:
 mov r2,r6

Regards,
Dimitar


On Monday, November 28, 2016 at 7:39:38 AM UTC+2, Neil Jubinville wrote:
>
> Ok I got it working,   the part I changed is commented out.
>
> Essentially I used my r6 debug register that had the correct one in it. 
>  Now I can dial in the blinky action! fun!
>
> So for some reason even though we were setting the r2 form the lbbo it 
> just did not like this syntax.
>
> *ldi r14, %lo( r6/4 )*
> * ldi r14.w2, %hi_rlz(r6/4)*
>
> *Seemed to always load the old initial value.   I have to search for the 
> %lo and %hi_rlz  meaning I know it is used to load a high and low set of 
> bytes due to limitations of ldi to a max of 65535 but it was probably 
> messing things up.*
>
>
>
> lbbo r2, r0, 8 ,4
> mov r6, r2   // to prove in the c program that data arrived and 
> is correct when displayed R2 should equal R6- debug
>
>
> sbbo  r0, r0, 0 , 48// copy all 12 registers to memory 
> R0...R11 .
>
>
> // the goal is for  R2 to get  set in a C program outside theis 
> assembly.   Thus changing the speed of the
>// blinking LED  - defualt is set to 1 second  = 200,000,000 
> cycles in CPU delay.
>
>
> // led on
> mov r30, r1
> mov r14,r6
> calldelay_n2_cycles
>
>
> // led off
> mov r30, r0
> mov r14, r6
> calldelay_n2_cycles
>
>
> /*
> // led on
>  mov r30, r1
>  ldi r14, %lo( r6/4 )
>  ldi r14.w2, %hi_rlz(r6/4)
>  call delay_n2_cycles
>
>
>  // led off
>  mov r30, r0
>  ldi r14, %lo(r6/4)
>  ldi r14.w2, %hi_rlz(r6/4 )
>  call delay_n2_cycles
> */
>
>
>
>
>
>
> On Sunday, November 27, 2016 at 10:09:55 PM UTC-7, Neil Jubinville wrote:
>>
>> Yes, thank-you, I already know the prompt cycle needs to run twice to 
>> pick up the write in the subsequent read cycle, no big deal there, I just 
>> enter the same vale twice and I get the feedback. 
>>
>> The part I am focused on is why the value from the LBBO does not seem to 
>> be used in the delay call.
>>
>> You may have missed my  last post where the LBBO worked using the 8 bytes 
>> of offset,  R2 is the third 32 bit number in my reference   R0 is the first 
>> , R1 the second, *R2 the third*
>>
>>   lbbo  r2, r0, 8 ,4works like a champ.
>>
>> After the lbbo I transfer the value I entered into R6 in the PRU and it 
>> comes back to me in the sbbo so I know it is working and getting to the 
>> general registers.
>>
>> The question now is why R2 used as a delay value does not change the 
>> delay time when it is truly reaching the PRU.
>>
>> Any comments on the initialization of R2 = 200,000,000 ?  does that 
>> syntax lock it into a constant?
>>
>>
>>
>>
>> On Sunday, November 27, 2016 at 7:12:38 PM UTC-7, Charles Steinkuehler 
>> wrote:
>>>
>>> On 11/27/2016 6:35 PM, Neil Jubinville wrote: 
>>> > 
>>> > Description of the program: 
>>> > 
>>> > An LED toggles on and off from a set delay time in R2. 
>>> > 
>>> > A separate C program loads the PRU program, starts the core and then 
>>> prompts the 
>>> > user for a Time to do a delay.   Upon the user entering a time, the c 
>>> program 
>>> > writes that value to dataram and reads back the mapped memory from the 
>>> PRU to show. 
>>> > 
>>> > The PRU loop does a SBBO each time as well as a LBBO for a single R2 . 
>>>   My LBBO 
>>> > call however is not returning the proper value, I am likely using the 
>>> wrong 
>>> > pointer value. 
>>> > 
>>> > Here is where I believe the problem is, how I interpret what register 
>>> address to 
>>> > start at by setting an arbitrary r9 to the start. 
>>> > 
>>> > *ldir9, 9  //  offset to the start of the 

Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram

[dinuxbg]

Hi, check my comments inline.

On Sunday, November 27, 2016 at 10:15:00 PM UTC+2, Neil Jubinville wrote:
>
> Thx Charles, that was it.   I was treating the registers as application of 
> dataram memory. 
>
> In the assembly loop:  I did a :  * sbbo  r0, r0, 0 , 48*
>
> and like magic my c pru memap dumped out values I have stuffed in some of 
> the registers.   
>
> see below
>
> -
> value R0 = 0
>  value R1 = 65535
> value R2 = 8192
> value R3 = 16
>  value R4 = 777
> value R5 = 25
> value R6 = -136853601
>  value R7 = 2146680819
> value R8 = 1
> value R9 = -45491713
>  value R10 = -89
> value R11 = -1345356802
>
> 
>
> I do have a more basic question though about the value in R2 = 8192.   My 
> understanding is the general purpose registers are 32 bit. 
>
>  In my assembly I set 
>
> *r2 =  0x0BEBC200   // *decimal 200,000,000  to reflect the core 
> frequency.
>
> however as you can see the R2 after the mem copy to dataram shows 8192.   
> Why is it not reading 200,000,000 in R2 after the transfer?   
>

Could you share your full source code? 

>
> -
>
> Also, another question.  Syntax wise the first *r0 *in the statement 
> below 'should' have  but I get unknown register error when compiling.   
> If I leave out the & it works and the transfer does occur.   Is this a 
> nuance of the gcc-pru compiler vs a direct pasm compile?
>
> *sbbo  r0, r0, 0 , 48*
>
Yes, the & is not needed for pru-gcc. But for the sake of compatibility 
I'll make it optional with the next release.

 

>
>
> Yet another question:  the second argument of *r0* reflects the starting 
> address point in dataram.  I would have expected dataram as a free for all 
> address space that I managed.   Is the reference of an Rn type syntax 
> simply a convenience for addressing in dataram and dataram has the notion 
> of its own register mapping?
>
Dataram has no register mapping. It is simply memory. Consider the 
following example:
ldi  r1, 101
ldi  r2, 64
sbbo r1, r2, 0, 4
Converted to C syntax, it would look like:
   unsigned int r1 = 101;
   unsigned int *r2 = (void *)64;
   r2[0] = r1;


 

>
>
> 
>
>
>
> *Thx!  *
>
>  
>
>
>
>
> On Saturday, November 26, 2016 at 12:43:37 PM UTC-7, Charles Steinkuehler 
> wrote:
>>
>> On 11/26/2016 1:33 PM, Neil Jubinville wrote: 
>> > 
>> > Here is my basic understanding - Focusing on PRU0: 
>> > 
>> > Each PRU has 8K of  'dataram'  - This is where I expect  R1,R2,R3  
>> R31 to be 
>> > stored. *Is this true? I see many people changing the reference at 
>> *0x_0n00, 
>> > n = c24_blk_index[3:0],   do I need to set where the Rn's lay down in 
>> memory? 
>>
>> NO 
>>
>> The data ram is what it says...data ram.  The registers are what they 
>> say...registers.  Registers are *NOT* data ram.  If you want the 
>> register values to appear in memory, you have to write them out using 
>> the SBBO instruction. 
>>
>> > Docs also state that the PRU 0 Data ram starts at *0x4a30*; 
>> > 
>> >  int registerStart; 
>> >  registerStart = *(int*)0x4a30; 
>> >  printf("--> R0 = %d" + registerStart); 
>> > 
>> > However I get a seg fault trying to print what is in R0 that way.  That 
>> was more 
>> > to just do a direct look see if possible and go around all the 
>> interfaces. 
>>
>> 0x4a30 is a physical address.  You can use that if you are 
>> directly accessing memory (via /dev/mem, bus-mastering DMA, or 
>> something that doesn't use an MMU like the PRU core).  If you try to 
>> access a physical address from a standard application that has not 
>> been mapped into your process memory space, the MMU will forbid access 
>> and your program seg-faults. 
>>
>> To access the PRU memory in your application, use the address provided 
>> to you by the prussdrv_map_prumem function. 
>>
>> -- 
>> 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/c2030086-f837-4957-ad35-d9d87cc54da4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Surefire PRU - Setup.

[dinuxbg]

Many thanks for the script. The blinking-led notes for UIO now point to it:
https://github.com/dinuxbg/pru-gcc-examples/tree/master/blinking-led#uio-host-driver

Regards,
Dimitar

On Saturday, November 26, 2016 at 9:49:57 PM UTC+2, Neil Jubinville wrote:
>
> Hi All,
>
> *Thanks for all the previous help*, I am happy to report that I have a 
> script that will download, install , configure a beaglebone for working pru 
> support.   It does this at the most basic level.  One blinking LED.
>
> Here is how to get a surefire setup if you are just learning about the PRU 
> and want to know you have a working base system.  Once you have a working 
> base you can build your knowledge from there and understand which pieces do 
> what.
>
> 1)Get this image :   * 
> https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz
>  
> <https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz>*
> install it on SD card / flash it to emmc. It is the release I used.
>
> 2) Login into your beaglebone black and run:
> *git clone **https://github.com/Neil-Jubinville/pru 
> <https://github.com/Neil-Jubinville/pru> *
>
> 3)  Thencd pru followed by./prep_pru.sh  and that will 
> kickoff the automatic setup.
>
> You can view the script details here: 
> https://github.com/Neil-Jubinville/pru/blob/master/prep_pru.sh
>
> In a nutshell - it upgrades the kernel to a know working version, rebuilds 
> device tree overlays, disables cape universal,  enables PRU support, loads 
> the uio_pruss module, downloads examples and sets one of them to run at 
> start up.  It will reboot your beaglebone so make your you are watching it 
> start so you can see it blink.
>
> To see it work, ultimately you will need an LED hooked up to P9.27 to 
> ground (and an inline resister likely).   
>
> Thx,
>
> Neil
>

-- 
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/f150b4ba-eaf9-43cc-8a0b-8e620e8dd497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU Example

[dinuxbg]

Could you double check that your pin mux is correct? On my kernel I can do 
it with this command:
   $ cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep -i 44e109a4

Which kernel are you using?

You may also try the "md5-check" example. If md5-check passes, then the PRU 
firmware is loaded and executed just fine. In such case you'll know that 
your "blinking-led" has an issue with the pin mux or LED wiring.

Regards,
Dimitar

On Monday, November 7, 2016 at 6:24:30 PM UTC+2, Neil Jubinville wrote:
>
> Thx Dimitar, 
>
> Ok so still no voltage toggle / led lighting on that  P9_27.Any idea 
> why the PRU will load but I am not seeing any I/O work?   
>
>  I am using this overlay  :
>
> root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat 
> /lib/firmware/BB-BONE-PRU-00A0.dts
> /*
> * Copyright (C) 2013 Matt Ranostay 
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "BB-BONE-PRU-01";
> version = "00A0";
>
> /* state the resources this cape uses */
> exclusive-use =
> /* the pin header uses */
> "P9.27", /* pru0: pr1_pru0_pru_r30_5 */
> /* the hardware IP uses */
> "pru0";
>
> fragment@0 {
> target = <_pinmux>;
> __overlay__ {
>
> pru_gpio_pins: pinmux_pru_gpio_pins {
> pinctrl-single,pins = <
> 0x1a4 0x0f /* P9 27 GPIO3_19: mcasp0_fsr.gpio3[19] | MODE7 | OUTPUT */
> >;
> };
>
> pru_pru_pins: pinmux_pru_pru_pins {
> pinctrl-single,pins = <
> 0x1a4 0x25 /* mcasp0_fsr.pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU */
> >;
> };
> };
> };
>
> fragment@2 {
> target = <>;
> __overlay__ {
> status = "okay";
>
> pinctrl-names = "default";
> pinctrl-0 = <_pru_pins>;
> };
> };
> };
> root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat $slots
> ^C
> root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat 
> /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  5: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-BONE-PRU 
>
>
>
> On Saturday, November 5, 2016 at 4:19:27 AM UTC-6, din...@gmail.com wrote:
>>
>> It means the Pru core is being stopped and reset. You may want to open 
>> pload.c and adjust the amount of time PRU is allowed to execute. By default 
>> it is 30 seconds. 
>>
>> Regards, 
>> Dimitar 
>>
>> On Saturday, November 5, 2016 at 9:13:50 AM UTC+2, Neil Jubinville wrote: 
>> > OK This worked for the loading: 
>> > 
>> > 
>> > 
>> > root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# 
>> ./out/pload ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf 
>> > Initializing the PRUs... 
>> > AM33XX 
>> > The code is 0Starting ... 
>> > Stopping PRU... done. 
>> > 
>> > 
>> > The I/O does not seem to toggle just yet,  I am loading the simple 
>>  BB-BONE-PRU that has one pin for output enabled -> P9.27  
>> > 
>> > 
>> > Getting close though.
>> > 
>> > 
>> > When the message says stopping PRU in the pruss driver is it stopping 
>> the cpu/core execution ?   or is that indicating the end of the load? 
>> > 
>> > 
>> > Neil 
>> > 
>> > 
>> > 
>> > 
>> > On Tuesday, November 1, 2016 at 2:02:02 PM UTC-6, RobertCNelson 
>> wrote:On Tue, Nov 1, 2016 at 2:57 PM, Robert Nelson  
>> wrote: 
>> > 
>> > > On Tue, Nov 1, 2016 at 2:51 PM, Neil Jubinville <
>> ne...@orbitalsoftware.ca> wrote: 
>> > 
>> > >> I am trying to avoid buying that TI cape :) 
>> > 
>> > >> 
>> > 
>> > >> OK update:   Indeed running the  updatekernel.sh brought me to 
>> 4.4.27   This 
>> > 
>> > >> gave me the ability to run modprobe uio_pruss 
>> > 
>> > >> 
>> > 
>> > >> When I go to run the loader I am still getting the prussdrv_open 
>> failed 
>> > 
>> > >> message.   This tells me that normally the PRUs may not be enabled 
>> and to 
>> > 
>> > >> look for the HDMI pin conflict?  Chatting in the #beagle irc states 
>> that the 
>> > 
>> > >> default open pin is not in conflict to open the PRU after the init 
>> so I am 
>> > 
>> > >> not sure what is going on.   Maybe this has to do with the base 
>> > 
>> > >> cap-universal tree loaded at the start. 
>> > 
>> > >> 
>> > 
>> > >> I have removed all DT from the slots till it was empty then loaded a 
>> variety 
>> > 
>> > >> of BB-BONE-PRU * and to no avail would it open/load.   So it is 
>> something 
>> > 
>> > >> more obscure.   I suspect the default DT. 
>> > 
>> > > 
>> > 
>> > > On the TI branch, we don't ship a default PRU driver, it's up to you 
>> > 
>> > > to configure it.. 
>> > 
>> > > 
>> > 
>> > > git clone https://github.com/RobertCNelson/dtb-rebuilder 
>> > 
>> > > cd ./dtb-rebuilder/ 
>> > 
>> > > 
>> > 
>> > > You have the "black", so edit one of the following: 
>> > 
>> > > 
>> > 
>> > > #default: emmc + hdmi enabled: 
>> > 
>> > > nano src/arm/am335x-boneblack.dts 
>> 

Re: [beagleboard] Re: Surefire PRU Example

[dinuxbg]

It means the Pru core is being stopped and reset. You may want to open pload.c 
and adjust the amount of time PRU is allowed to execute. By default it is 30 
seconds.

Regards,
Dimitar

On Saturday, November 5, 2016 at 9:13:50 AM UTC+2, Neil Jubinville wrote:
> OK This worked for the loading:
> 
> 
> 
> root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# ./out/pload 
> ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf
> Initializing the PRUs...
> AM33XX
> The code is 0Starting ...
> Stopping PRU... done.
> 
> 
> The I/O does not seem to toggle just yet,  I am loading the simple  
> BB-BONE-PRU that has one pin for output enabled -> P9.27 
> 
> 
> Getting close though.   
> 
> 
> When the message says stopping PRU in the pruss driver is it stopping the 
> cpu/core execution ?   or is that indicating the end of the load?
> 
> 
> Neil
> 
> 
> 
> 
> On Tuesday, November 1, 2016 at 2:02:02 PM UTC-6, RobertCNelson wrote:On Tue, 
> Nov 1, 2016 at 2:57 PM, Robert Nelson  wrote:
> 
> > On Tue, Nov 1, 2016 at 2:51 PM, Neil Jubinville  
> > wrote:
> 
> >> I am trying to avoid buying that TI cape :)
> 
> >>
> 
> >> OK update:   Indeed running the  updatekernel.sh brought me to 4.4.27   
> >> This
> 
> >> gave me the ability to run modprobe uio_pruss
> 
> >>
> 
> >> When I go to run the loader I am still getting the prussdrv_open failed
> 
> >> message.   This tells me that normally the PRUs may not be enabled and to
> 
> >> look for the HDMI pin conflict?  Chatting in the #beagle irc states that 
> >> the
> 
> >> default open pin is not in conflict to open the PRU after the init so I am
> 
> >> not sure what is going on.   Maybe this has to do with the base
> 
> >> cap-universal tree loaded at the start.
> 
> >>
> 
> >> I have removed all DT from the slots till it was empty then loaded a 
> >> variety
> 
> >> of BB-BONE-PRU * and to no avail would it open/load.   So it is something
> 
> >> more obscure.   I suspect the default DT.
> 
> >
> 
> > On the TI branch, we don't ship a default PRU driver, it's up to you
> 
> > to configure it..
> 
> >
> 
> > git clone https://github.com/RobertCNelson/dtb-rebuilder
> 
> > cd ./dtb-rebuilder/
> 
> >
> 
> > You have the "black", so edit one of the following:
> 
> >
> 
> > #default: emmc + hdmi enabled:
> 
> > nano src/arm/am335x-boneblack.dts
> 
> >
> 
> > #: all overlays (emmc/hdmi disabled)
> 
> > nano src/arm/am335x-boneblack-overlay.dts
> 
> >
> 
> > #emmc enabled: hdmi disabled
> 
> > src/arm/am335x-boneblack-emmc-overlay.dts
> 
> >
> 
> > then look:
> 
> 
> 
> Opps reversed them:
> 
> 
> 
> uio_pruss (3.8.x compatible)
> 
> 
> 
> /*
> 
> * /etc/modprobe.d/pruss-blacklist.conf
> 
> *
> 
> * blacklist pruss
> 
> * blacklist pruss_intc
> 
> * blacklist pru-rproc
> 
> */
> 
> /* #include "am33xx-pruss-uio.dtsi" */
> 
> 
> 
> remoteproc (v4.4.x-ti)
> 
> 
> 
> /*
> 
> * /etc/modprobe.d/pruss-blacklist.conf
> 
> *
> 
> * blacklist uio_pruss
> 
> */
> 
> /* #include "am33xx-pruss-rproc.dtsi" */
> 
> 
> 
> 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/b0b461b3-5e0b-4ed5-aba4-48b8b74de6d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Surefire PRU Example

[dinuxbg]

Hi Neil,

I think that for UIO you'll need to switch your kernel. See 
https://groups.google.com/d/msg/beagleboard/6vKLJpJoPGY/kc-iW_fbAgAJ .

For remoteproc, here are some points to check:

   1. For loading PRU GCC ELF firmware you will need a kernel with this 
   patch applied: 
   0001-Fix-remoteproc-to-work-with-the-PRU-GNU-Binutils-por.patch 
   
<https://github.com/dinuxbg/pru-gcc-examples/blob/master/blinking-led/host-remoteproc/0001-Fix-remoteproc-to-work-with-the-PRU-GNU-Binutils-por.patch>.
 
   Looks like your kernel 4.4.9-ti-rt-r25 is missing it. The Jessie testing 
   images 
   
<http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots>
 
   come with 4.4.27-ti-rt-r62 , which has this patch integrated. 
   2. If you are using RPMSG communication, then please be aware that there 
   are two remoteproc drivers circulating around :( The older one uses 
   mailboxes for RPC (corresponding pru-gcc-examples branch "master"). If your 
   kernel is newer, it probably runs the remoteproc driver that instead uses 
   interrupts for RPC. You'll want to use the dev-for-v5-rpmsg 
   <https://github.com/dinuxbg/pru-gcc-examples/tree/dev-for-v5-rpmsg> branch 
   of pru-gcc-example, which is based on the updated "5.0.0" 
   pru-software-support-package from TI.

Regards,
Dimitar


On Monday, October 31, 2016 at 8:02:49 PM UTC+2, Neil Jubinville wrote:
>
> Hi All, 
>
> I have BBB rev c recently flashed to Debian 8 - kernel 4.4.   I have been 
> struggling to get code into the PRUs since many of the demos on the web are 
> fragmented in methods and dependencies which make it difficult to have a 
> winning combination.  My goal is to have a configuration script that can 
> setup all the requirements for the PRU to work.  
>
> I also noticed that many users appear to be using uio_pruss for their 
> loader and not remote_proc.  That said what img is the last known working 
> image with uio_pruss ?
>
> In the latest site listed image, *uio_pruss module seems not to be 
> included*,  is there a separate package we need to install for this 
> support? 
>
> I am able to compile using gcc-pru and build elf files form the various 
> demos.  In general I am trying to do this basic one 
> https://github.com/Neil-Jubinville/pru-gcc-examples/tree/master/blinking-led 
>   and use my init script here: 
> https://github.com/Neil-Jubinville/pru/blob/master/prep_pru.sh
>
> *Using the uio_pruss method: *
> - I get uio_pruss not found for the module.   Therefore subsequent 
> commands yield:
>
> root@beaglebone:~/pru-gcc-examples/blinking-led/host-uio# ./out/pload 
> ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf
> Initializing the PRUs...
> pload: prussdrv_open open failed   ( how to get uio_pruss ? Do I have to 
> compile this module? )
>
> *Using the remote_proc method:*
>
> The below commands fail with the module not found*.   *
>
> sudo rmmod pruss_remoteproc
> sudo modprobe pruss_remoteproc
>
>
> So I am not having success with either method, each having missing 
> dependencies.   The startup log below indicates also some availability and 
> failing of default PRU loading from the /lib/firmware copies of the remote 
> proc method.
>
> *Any ideas? Is there a surfire version / image that will 100% resulting 
> gcc-pru compiled example loading into PRU.  I will certainly document it 
> once I discover it.*
>
> BeagleBoard.org Debian Image 2016-05-13
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> root@beaglebone:~# uname -a
> *Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l 
> GNU/Linux*
> root@beaglebone:~# lsmod
> Module  Size  Used by
> c_can_platform  6602  0
> c_can   9577  1 c_can_platform
> can_dev11663  1 c_can
> spidev  7523  0
> pwm_tiecap  3652  0
> pwm_tiehrpwm4706  0
> tieqep  8758  0
> pruss_intc  3571  0
> snd_soc_hdmi_codec  5842  1
> snd_soc_simple_card 8449  0
> 8021q  17930  0
> garp5769  1 8021q
> mrp 7239  1 8021q
> stp 2219  1 garp
> llc 5123  2 stp,garp
> *pru_rproc  11359  0*
> omap_aes_driver19045  0
> omap_sham  21340  0
> pruss  11679  1 pru_rproc
> omap_rng4423  0
> snd_soc_davinci_mcasp16653  2
> snd_soc_edma1290  1 snd_soc_davinci_mcasp
> snd_soc_omap3058  1 snd_soc_davinci_mcasp
> rng_core7703  1 omap_rng
> tilcdc 26338  0
> usb_f_acm 

[beagleboard] Re: Want to PRU binary using prussdrv_exec_program - Can't seem to get .bin file loading on PRU

[dinuxbg]

Paul,

The "combined" image is actually a standard ELF file. You may load and 
parse it yourself using libelf. Here is an example for pru-gcc that loads 
an ELF image, extracts IMEM and DMEM sections, and feeds them to the UIO 
loader: 
 
https://github.com/dinuxbg/pru-gcc-examples/blob/master/blinking-led/host-uio/pload.c

I have not tested it, but in theory it should also work with TI's toolchain.

Regards,
Dimitar

On Friday, September 16, 2016 at 7:02:10 PM UTC+3, paulandre...@gmail.com 
wrote:
>
> Hi,
>   Wondering if anyone can help. I had the Remote Proc/RpMsg working 
> passing data to and fro. However I liked the functionality of uio_pruss so 
> I have updated my kernel to 4.4.20-ti-r44 following advice from some of the 
> guys on the board. Thanks to all who responded last time, uio_pruss is what 
> I need.
>
> So I have rebuilt my device tree to include am33xx-pruss-io.dtsi. and 
> installed under the kernel directory in /boot/dtbs. I reboot and when I run 
> lsmod I can see the three uio kernel objects. I am sure it is using the 
> rebuilt device tree because I turned off the heartbeat on the USR0 led as a 
> test in the am335x-common.dtsi. It isn't toggling anymore. 
>
> I have built an example PRU program, PRU_LED0. I have setup the hex 
> utility to run the following cmd file
>
> --b
> --image
>
> ROMS {
> PAGE 0:
> .text: o = 0x0, l = 0x2000, files={text.bin}
> PAGE 1:
> .data: o = 0x0, l = 0x2000, files={data.bin}
> }
>
> I have an error, if I use this it complains 'not enough files for ".text" 
> and ".data". So I removed the files command to make it like what I built 
> for Remotew Proc/RpMsg and it builds a _image.obj. Trouble is that it is 
> the test and data combined. The rp_proc loader I think can split the file 
> and load text and data. However I can't see a way to split them for using 
> with uio_pruss which calls prussdrv_exec_program and 
> prussdrv_load_datafile. 
>
> Is there a utility or macro I could use to find the data and text portions 
> of the image obj and split them ?
>
> I am pretty sure this is the problem. I took portions of the 
> prussdrv_exec_program function into my programm to see where the calls 
> fails. I seem to be able to run prussdrv_pru_disable. It is failing at 
> prussdrv_pru_write_memory, just before it calls prussdrv_pru_enable_at to 
> run the code.
>
> Fustrating... I am sure I am missing something obvious.
>
> Cheers,
> Paul
>
>
>
>  
>

-- 
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/5da48903-2f6e-4b9c-a450-127a56813119%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to use PRU constants table?

[dinuxbg]

Hi Karl,

These constants allow the C compiler to produce more efficient code. Of 
course you can also use them in assembly programs by explicitly using 
lbco/sbco instructions.

Let me give you an example how pru-gcc uses the constant table. Consider 
this C code snippet:
# define MYREG   ( * (volatile uint32_t *)(0x4802A000 + 0x24))
MYREG = 42;


Normally pru-gcc would output the following:
ldi r14, %lo(1208131620)
ldi r14.w2, %hi_rlz(1208131620)
ldi r15, 42
sbbor15, r14, 0, 4

But you can tell the compiler that this address base is special (btw, 
already defined for you in ):
#pragma ctable_entry 2 0x4802a000
Then the compiler can produce a much shorter instruction sequence:
ldi r14, 42
sbcor14, 2, 36, 4

TI's compiler uses a different syntax for the constants declarations, but 
essentially does the same optimization.

Regards,
Dimitar

On Friday, July 15, 2016 at 11:41:06 AM UTC+3, Karl Karpfen wrote:
>
> Hi,
>
> the AM335x TRM specifies a constants table for PRU which can be used for 
> easier access of memory addresses. As an example: for I2C1 registers which 
> originally use base-address 0x4802A000 a constant 2 is defined.
>
> What I do not understand: how can one use these constants? How does the 
> mapping from a constant to a base-address work where I have to add an 
> offset in order to access desired registers?
>
> Or is this an assembler-thingy only which can't be used out of 
> PRU-C-Software?
>
> 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/720f7e7d-d6ee-4498-851f-8cb5a2fa5087%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

[dinuxbg]

Hi William,

I have marked the release as "ready for cautious usage" merely because I 
seem to be the only user so far :) Once I see enough non-trivial projects 
using it, I will remove that wording. While it may not yet have matured 
into a production quality toolchain, I wouldn't call pru-gcc a toy compiler.

I admit the pru-gcc port had a rough start. But I corrected this by writing 
real-world examples and running the GCC testsuite through a simulator. Bugs 
were found and fixed.

The pru-gcc test results you pointed are actually pretty good. The 31 
unexpected failures are due to reasons like: broken features that are not 
applicable to PRU, code optimizations that were not applied. I am not aware 
of any wrong-code-generation bugs. I'm also working on cleaning up the 
report to avoid further confusion (issue #16 
<https://github.com/dinuxbg/gnupru/issues/16>). You can compare the pru 
results against the mainline gcc test report for x86: 
https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00235.html

Using pru-gcc you gain GCC - free and familiar compiler. Admittedly, right 
now CCS generates a bit more optimized code than pru-gcc. And CCS has 
received more testing than pru-gcc.

Regards,
Dimitar

On Tuesday, July 12, 2016 at 4:47:50 AM UTC+3, William Hermans wrote:
>
> heh I forgot that "readme dot md's" actually link to some random github 
> project heh. So . . 
>
> The release is ready for cautious usage. A simulator is used to execute 
>> the GCC C regression test suite. Results for this release are:
>>
>> # of expected passes   81497
>> # of unexpected failures   31
>> # of unexpected successes  1
>> # of expected failures 97
>> # of unsupported tests 1974
>>
>>
> This message has changed some since the last time I read it but pretty 
> much the same result. In my mind - Don't use it. 
>
>
> On Mon, Jul 11, 2016 at 6:44 PM, William Hermans <yyr...@gmail.com 
> > wrote:
>
>> Jason:
>>>   I'm using gcc on the ARM and clpru on the PRU.  Both are installed.
>>>
>>> What would you gain by using gcc on the PRU?
>>>
>>> --Mark
>>>
>>
>> Let me answer this for you Mark. You would gain nothing. The contributor 
>> of the pru gcc implementation hints that it's nothign more than a toy, and 
>> that code generated with it should be thought of nothign more than 
>> experimental. It says this right on the github project page readme.md.
>>
>> On Mon, Jul 11, 2016 at 6:39 PM, William Hermans <yyr...@gmail.com 
>> > wrote:
>>
>>> Hi Mark,
>>>
>>> Well I do not know, what would be the simplest example that is close 
>>> enough to the traditional hello world app ? I was thinking perhaps blinking 
>>> a USR LED, since one would not have to add any additional hardware. But I 
>>> looked into that a while back, and doing this would not be a trivial matter 
>>> I think. Well actually . . . it depends on how remoteproc is implemented. 
>>> If remoteproc can gain direct access to CPU memory addressing as can be 
>>> done using uio_pruss. Then it should not be too much trouble.
>>>
>>> So maybe an external LED example? Which would work out very close to how 
>>> one would toggle a GPIO( LED ) on a bare metal platform.  So anyone having 
>>> background experience with something like a TI Launchpad or Arduino should 
>>> be able to understand this very easily.
>>>
>>> Passed that . . some kind of communication example. I was thinking 
>>> perhaps usrspace to PRU core 1, to PRU core 2, then back to userspace. As a 
>>> way for people to get their feet wet, with something easily verifiable. 
>>> Then perhaps a shared memory example.
>>>
>>>
>>> On Mon, Jul 11, 2016 at 6:14 PM, Mark A. Yoder <mark.a...@gmail.com 
>>> > wrote:
>>>
>>>> Greg:
>>>>   I tried removing the symbolic links and I get the following error 
>>>> when running make on a BeagleScope example.
>>>>
>>>> Invoking: PRU Compiler
>>>> /usr/share/ti/cgt-pru/bin/clpru 
>>>> --include_path=/usr/share/ti/cgt-pru/include 
>>>> --include_path=../../../include --include_path=../../../include/am335x -v3 
>>>> -O2 --display_error_number --endian=little --hardware_mac=on 
>>>> --obj_directory=gen --pp_directory=gen -ppd -ppa -fe 
>>>> gen/PRU_gpioToggle.object PRU_gpioToggle.c
>>>> make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
>>>> Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed
>>>>

[beagleboard] Re: Is it possible to write PRU firmware for remoteproc completely in Assembler?

[dinuxbg]

Nico, 

There are two prerequisites for your PRU firmware to be loaded by the 
remoteproc d 
river: 
1. PRU firmware image must be in ELF format. Only TI's clpru and the 
unofficial G
NU PRU toolchain support this. 
2. PRU firmware must include a ".resource_table" ELF section containing a 
resourc
e table. 

You cannot use PASM with remoteproc because PASM cannot output ELF. 

Here is a GNU assembler example that can be loaded and executed by 
remoteproc: htt
ps://github.com/dinuxbg/pru-gcc-examples/blob/master/blinking-led/pru/main1.
S . Yo
u should be able to write something similar for TI's clpru assembler. But 
as others 
have pointed, it is more sensible to start with C and optimize only the 
critical p
arts of your program in assembly. 

Regards, 
Dimitar


On Friday, February 19, 2016 at 9:04:30 PM UTC+2, Nicolas Dammin wrote:
>
>
> Hi, 
>
> I'm using the AM335X Starter Kit from TI with an AM3359 SoC and I use the 
> TI Processor SDK Linux version 02.00.01.07. I managed to get remoteproc 
> driver working, then I removed the Display module and used the flatflex 
> connector to breakout some GPIOs of PRU1 to hook up some LEDs. I wrote a 
> blink-led firmware in CCS v6 as described in the PRU HandsOn Lab and 
> successfully bootet the PRU1 to let my LEDs blink.
>
> Now I need to write a very fast code so I have to write it in Assembly 
> language. I would like to use the AM335x PRU-ICSS Reference Guide to write 
> my code and use the PASM compiler.
>
> Is it possible to write pure assembler code like with the PASM and make 
> the code work for the newer remoteproc? Or can I write assembly code in 
> CodeComposer Studio with the TI compiler? I couldn't figure out yet how I 
> can do that. Is there a Tutorial somewhere?
>
> I read that TI does not support PRU so good so this is why I ask here.
>
> Regards
> Nico
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates thread

[dinuxbg]

One more URL with examples: 
https://github.com/dinuxbg/pru-software-support-package . This is a fork of 
the TI PRU Traning that is ported to GCC. So far lab5 is finished and was 
tested successfully on RCN's 2015-11-15 image (kernel 4.1.13-ti-r30).

понеделник, 2 ноември 2015 г., 23:35:42 UTC+2, RobertCNelson написа:
>
> On Mon, Nov 2, 2015 at 3:31 PM, William Hermans <yyr...@gmail.com 
> > wrote: 
> > John, 
> > 
> > Not an argument so much as a concern . . . those hands-on labs are 
> specific 
> > to CCS, with no clear way of proceeding otherwise. e.g. I'd much prefer 
> a 
> > GNU approach. But I'll gloss over those labs yet again . . . and read 
> what 
> > other information is out there to see if this can be done with a gcc 
> > toolchain. 
> > 
> > CCS is a fine IDE, and set of tools, but not everyone has the need, or 
> even 
> > want / capability to use such a tool. 
>
> The ti-pru compiler is available by default in the beagleboard.org 
> images..  So ccs project's just be transferable/buildable on the 
> beagle.. 
>
> btw, the pru gnu examples are here, and i've gotten a patch from it's 
> author, so they should also be working in v4.1.x ;) 
>
> https://github.com/dinuxbg/pru-gcc-examples 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Replacing Robotis robot controllers with BBB

[dinuxbg]

Yes, i2cdetect should detect the camera. The C code in host/ov7670-i2c.c 
 is tested and works.

But there are important prerequisites for the OV7670 I2C communication:
  - Ensure XCLK is running.
  - Pulse the RESET line and leave it set to VCC. 
  - Either leave PWDN Not Connected (it has a built-in pull-down), or 
connect to GCC.

Regards,
Dimitar

събота, 1 август 2015 г., 23:44:35 UTC+3, Bill M написа:

 Oh, but I don't have the PWDN and RESET pins on the OV7670 connected.

 On Saturday, August 1, 2015 at 4:41:55 PM UTC-4, Bill M wrote:

 Greetings Dimitar,

 Sorry to bother you again. Were you able to get the I2C working with the 
 OV7670? I have it wired up as you do and am trying to read it in Debian 
 using i2cdetect. Should i2cdetect be able to read the SCCB bus? Any help 
 appreciated.

 Thanks,
 Bill


 On Thursday, July 9, 2015 at 4:27:41 PM UTC-4, din...@gmail.com wrote:

 Hi,

 For prototyping I used 4inch cables, dispersed as far apart from each 
 other as possible. I had issues due to crosstalk between the wires.

 You could try using a ribbon cable where every second wire is connected 
 to ground (akin to 80-wire 40-pin IDE cables). Try to keep all wire lengths 
 roughly the same.

 Regards,
 Dimitar

 четвъртък, 9 юли 2015 г., 3:42:44 UTC+3, Bill M написа:

 Greetings Dimitar,

 I was wondering if you could offer me some more guidance? I managed to 
 get an OV7670 working with the PRU (I'm using PRU1), but I have noticed an 
 issue. If the VSYNC, HREF, PCLK, and XCLK wires are more than 4 inches 
 long, I get some incomplete or corrupted scan lines. Shorter than 4 
 inches, 
 the picture is perfect. Can you tell me how long are the wires you are 
 using? Any idea how I can overcome this limitation? Any help appreciated!

 On Thursday, April 30, 2015 at 5:06:54 PM UTC-4, din...@gmail.com 
 wrote:

 If you download the above project you'll find:
 README.md - general notes on the OV7670 example
 ov7670-cam/pru-ov7670-cape/kicad/ - KiCad schematic and PCB design
 ov7670-cam/pru-ov7670-cape/releases/ - PDF schematic and gerbers

 I did not put buffers because straight connection works fine for me. 
 But for any semi-serous use you should put buffers between the OV7670 
 (2.7V) and Beaglebone (3.3V). That said, the connection is 
 straightforward:

  lcd_data0.pr1_pru1_pru_r30_0 - do not connect
  lcd_data1.pr1_pru1_pru_r30_1 - XCLK
  lcd_data2.pr1_pru1_pru_r31_2 - D0
  lcd_data2.pr1_pru1_pru_r31_3 - D1
  lcd_data3.pr1_pru1_pru_r31_4 - D2
  lcd_data4.pr1_pru1_pru_r31_5 - D3
  lcd_data5.pr1_pru1_pru_r31_6 - D4
  lcd_data6.pr1_pru1_pru_r31_7 - D5
  lcd_vsync.pr1_pru1_pru_r31_8 - D6
  lcd_hsync.pr1_pru1_pru_r31_9 - D7
  lcd_pclk.pr1_pru1_pru_r31_10 - HREF
  lcd_ac_bias_en.pr1_pru1_pru_r31_11 - VSYNC
  uart1_rxd.pr1_pru1_pru_r31_16 - PCLK
  gpmc_advn_ale.gpio2_2 - CAM_RESET

 Regards,
 Dimitar

 сряда, 29 април 2015 г., 19:36:33 UTC+3, Bill M написа:

 Greetings Dimitar,

 I can't thank you enough for the direction (I was afraid no one would 
 want to slog through all that). I'm also interested in the hardware part 
 of 
 it. Are there any schematics for interfacing the camera to the board 
 (will 
 I need caps, resistors, voltage translations)? The few I have found 
 online 
 aren't completely clear. I may still go the OS route if the learning 
 curve 
 isn't too steep. I would still love to learn how to handle the PRU stuff 
 in 
 bare metal, though, so I need to get busier with the Starterware. Again, 
 thanks for the help!

 On Tuesday, April 28, 2015 at 4:13:59 PM UTC-4, din...@gmail.com 
 wrote:

 Hi,ov7670-cam/pru-ov7670-cape/releases/

 The servo control sounds like a job for the PRU. PRU I/O is also 
 suitable for interfacing OV7670. Here is a rough but working example 
 for 
 Beaglebone White: 
 https://github.com/dinuxbg/pru-gcc-examples/tree/master/ov7670-cam/pru 
 . Note that the example loader uses Linux and uio_pruss driver instead 
 of 
 Starterware.

 Regards,
 Dimitar


 понеделник, 27 април 2015 г., 16:28:40 UTC+3, Bill M написа:

 Greetings all, 


 I'll apologize for the big lead up, I just want everyone to know 
 where I'm coming from. I also apologize if I posted this to the wrong 
 place 
 or reposted it. I'm new here and still finding my way around.


 I am considering getting a BBB to use with my Robotis robot kit to 
 replace the CM-5 and CM-530 I've been using, and was hoping people 
 here 
 could give me help/advice/guidance, or direct me to those who can, as 
 I 
 have a million questions. I will start to list them here. Any help 
 greatly 
 appreciated in advance.


 I've already written firmware for both the CM-5 (which is Atmega128 
 powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), 
 You 
 can see the source for these here: 
 http://sourceforge.net/projects/bioloidfirmware/ Obviously these 
 are bare metal firmware given that the extremely limited platform in 
 both 
 cases couldn't practically support an OS. I would like to port my code

[beagleboard] Re: Replacing Robotis robot controllers with BBB

[dinuxbg]

Hi,

For prototyping I used 4inch cables, dispersed as far apart from each other 
as possible. I had issues due to crosstalk between the wires.

You could try using a ribbon cable where every second wire is connected to 
ground (akin to 80-wire 40-pin IDE cables). Try to keep all wire lengths 
roughly the same.

Regards,
Dimitar

четвъртък, 9 юли 2015 г., 3:42:44 UTC+3, Bill M написа:

 Greetings Dimitar,

 I was wondering if you could offer me some more guidance? I managed to get 
 an OV7670 working with the PRU (I'm using PRU1), but I have noticed an 
 issue. If the VSYNC, HREF, PCLK, and XCLK wires are more than 4 inches 
 long, I get some incomplete or corrupted scan lines. Shorter than 4 inches, 
 the picture is perfect. Can you tell me how long are the wires you are 
 using? Any idea how I can overcome this limitation? Any help appreciated!

 On Thursday, April 30, 2015 at 5:06:54 PM UTC-4, din...@gmail.com wrote:

 If you download the above project you'll find:
 README.md - general notes on the OV7670 example
 ov7670-cam/pru-ov7670-cape/kicad/ - KiCad schematic and PCB design
 ov7670-cam/pru-ov7670-cape/releases/ - PDF schematic and gerbers

 I did not put buffers because straight connection works fine for me. But 
 for any semi-serous use you should put buffers between the OV7670 (2.7V) 
 and Beaglebone (3.3V). That said, the connection is straightforward:

  lcd_data0.pr1_pru1_pru_r30_0 - do not connect
  lcd_data1.pr1_pru1_pru_r30_1 - XCLK
  lcd_data2.pr1_pru1_pru_r31_2 - D0
  lcd_data2.pr1_pru1_pru_r31_3 - D1
  lcd_data3.pr1_pru1_pru_r31_4 - D2
  lcd_data4.pr1_pru1_pru_r31_5 - D3
  lcd_data5.pr1_pru1_pru_r31_6 - D4
  lcd_data6.pr1_pru1_pru_r31_7 - D5
  lcd_vsync.pr1_pru1_pru_r31_8 - D6
  lcd_hsync.pr1_pru1_pru_r31_9 - D7
  lcd_pclk.pr1_pru1_pru_r31_10 - HREF
  lcd_ac_bias_en.pr1_pru1_pru_r31_11 - VSYNC
  uart1_rxd.pr1_pru1_pru_r31_16 - PCLK
  gpmc_advn_ale.gpio2_2 - CAM_RESET

 Regards,
 Dimitar

 сряда, 29 април 2015 г., 19:36:33 UTC+3, Bill M написа:

 Greetings Dimitar,

 I can't thank you enough for the direction (I was afraid no one would 
 want to slog through all that). I'm also interested in the hardware part of 
 it. Are there any schematics for interfacing the camera to the board (will 
 I need caps, resistors, voltage translations)? The few I have found online 
 aren't completely clear. I may still go the OS route if the learning curve 
 isn't too steep. I would still love to learn how to handle the PRU stuff in 
 bare metal, though, so I need to get busier with the Starterware. Again, 
 thanks for the help!

 On Tuesday, April 28, 2015 at 4:13:59 PM UTC-4, din...@gmail.com wrote:

 Hi,ov7670-cam/pru-ov7670-cape/releases/

 The servo control sounds like a job for the PRU. PRU I/O is also 
 suitable for interfacing OV7670. Here is a rough but working example for 
 Beaglebone White: 
 https://github.com/dinuxbg/pru-gcc-examples/tree/master/ov7670-cam/pru 
 . Note that the example loader uses Linux and uio_pruss driver instead of 
 Starterware.

 Regards,
 Dimitar


 понеделник, 27 април 2015 г., 16:28:40 UTC+3, Bill M написа:

 Greetings all, 


 I'll apologize for the big lead up, I just want everyone to know where 
 I'm coming from. I also apologize if I posted this to the wrong place or 
 reposted it. I'm new here and still finding my way around.


 I am considering getting a BBB to use with my Robotis robot kit to 
 replace the CM-5 and CM-530 I've been using, and was hoping people here 
 could give me help/advice/guidance, or direct me to those who can, as I 
 have a million questions. I will start to list them here. Any help 
 greatly 
 appreciated in advance.


 I've already written firmware for both the CM-5 (which is Atmega128 
 powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), You 
 can see the source for these here: 
 http://sourceforge.net/projects/bioloidfirmware/ Obviously these are 
 bare metal firmware given that the extremely limited platform in both 
 cases 
 couldn't practically support an OS. I would like to port my code to the 
 BBB. I want to stick with the bare metal approach, so I can go real time 
 without having to use a patch for the OS or Xenomai, and since I won't be 
 interested in a good part of the functionality of the board initially 
 (also 
 I'm kind of a big Linux noob). I have already downloaded StarterWare and 
 started poking around. The big draw for me to BBB is the processor clock 
 speed (the CM-5 is just 16Mhz, the CM-530 not much better at 72), the 
 huge 
 memory (for the controllers I'm using now, we're measuring in Kb), and 
 the 
 huge number for GPIOs (the CM-5 has none, the CM-530 only has a few). So 
 here are some of my initial questions:


 •Is anything special required to use the full 512MB memory? In other 
 words, can I directly address all the available memory without having to 
 go 
 through any special procedures? Could I theoretically declare a really 
 big 
 structure (iike a MB or 2) or array and be able

[beagleboard] Re: I/O ports for OV7670 data

[dinuxbg]

You'll need a high speed parallel input port, like GPMC or PRU. You'll have 
to program it to match the OV7670's data interface.

One of the examples here shows how to connect OV7670 via PRU, including 
schematics: https://github.com/dinuxbg/pru-gcc-examples.

Regards,
Dimitar

понеделник, 1 юни 2015 г., 6:19:22 UTC+3, lki...@gmail.com написа:

 I'm going to interface OV7670 board camera module with BBB like the 
 following site. 

 http://embeddedprogrammer.blogspot.kr/2012/07/hacking-ov7670-camera-module-sccb-cheat.html

 But I couldn't find I/O ports in BBB to be used to receive data from the 
 camera. The camera uses Digital Video Ports including 8~9 pins. Could 
 anyone let me know which ports(SPI, I2C, UART) I can use? 



-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Replacing Robotis robot controllers with BBB

[dinuxbg]

If you download the above project you'll find:
README.md - general notes on the OV7670 example
ov7670-cam/pru-ov7670-cape/kicad/ - KiCad schematic and PCB design
ov7670-cam/pru-ov7670-cape/releases/ - PDF schematic and gerbers

I did not put buffers because straight connection works fine for me. But 
for any semi-serous use you should put buffers between the OV7670 (2.7V) 
and Beaglebone (3.3V). That said, the connection is straightforward:

 lcd_data0.pr1_pru1_pru_r30_0 - do not connect
 lcd_data1.pr1_pru1_pru_r30_1 - XCLK
 lcd_data2.pr1_pru1_pru_r31_2 - D0
 lcd_data2.pr1_pru1_pru_r31_3 - D1
 lcd_data3.pr1_pru1_pru_r31_4 - D2
 lcd_data4.pr1_pru1_pru_r31_5 - D3
 lcd_data5.pr1_pru1_pru_r31_6 - D4
 lcd_data6.pr1_pru1_pru_r31_7 - D5
 lcd_vsync.pr1_pru1_pru_r31_8 - D6
 lcd_hsync.pr1_pru1_pru_r31_9 - D7
 lcd_pclk.pr1_pru1_pru_r31_10 - HREF
 lcd_ac_bias_en.pr1_pru1_pru_r31_11 - VSYNC
 uart1_rxd.pr1_pru1_pru_r31_16 - PCLK
 gpmc_advn_ale.gpio2_2 - CAM_RESET

Regards,
Dimitar

сряда, 29 април 2015 г., 19:36:33 UTC+3, Bill M написа:

 Greetings Dimitar,

 I can't thank you enough for the direction (I was afraid no one would want 
 to slog through all that). I'm also interested in the hardware part of it. 
 Are there any schematics for interfacing the camera to the board (will I 
 need caps, resistors, voltage translations)? The few I have found online 
 aren't completely clear. I may still go the OS route if the learning curve 
 isn't too steep. I would still love to learn how to handle the PRU stuff in 
 bare metal, though, so I need to get busier with the Starterware. Again, 
 thanks for the help!

 On Tuesday, April 28, 2015 at 4:13:59 PM UTC-4, din...@gmail.com wrote:

 Hi,ov7670-cam/pru-ov7670-cape/releases/

 The servo control sounds like a job for the PRU. PRU I/O is also suitable 
 for interfacing OV7670. Here is a rough but working example for Beaglebone 
 White: 
 https://github.com/dinuxbg/pru-gcc-examples/tree/master/ov7670-cam/pru . 
 Note that the example loader uses Linux and uio_pruss driver instead of 
 Starterware.

 Regards,
 Dimitar


 понеделник, 27 април 2015 г., 16:28:40 UTC+3, Bill M написа:

 Greetings all, 


 I'll apologize for the big lead up, I just want everyone to know where 
 I'm coming from. I also apologize if I posted this to the wrong place or 
 reposted it. I'm new here and still finding my way around.


 I am considering getting a BBB to use with my Robotis robot kit to 
 replace the CM-5 and CM-530 I've been using, and was hoping people here 
 could give me help/advice/guidance, or direct me to those who can, as I 
 have a million questions. I will start to list them here. Any help greatly 
 appreciated in advance.


 I've already written firmware for both the CM-5 (which is Atmega128 
 powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), You 
 can see the source for these here: 
 http://sourceforge.net/projects/bioloidfirmware/ Obviously these are 
 bare metal firmware given that the extremely limited platform in both cases 
 couldn't practically support an OS. I would like to port my code to the 
 BBB. I want to stick with the bare metal approach, so I can go real time 
 without having to use a patch for the OS or Xenomai, and since I won't be 
 interested in a good part of the functionality of the board initially (also 
 I'm kind of a big Linux noob). I have already downloaded StarterWare and 
 started poking around. The big draw for me to BBB is the processor clock 
 speed (the CM-5 is just 16Mhz, the CM-530 not much better at 72), the huge 
 memory (for the controllers I'm using now, we're measuring in Kb), and the 
 huge number for GPIOs (the CM-5 has none, the CM-530 only has a few). So 
 here are some of my initial questions:


 •Is anything special required to use the full 512MB memory? In other 
 words, can I directly address all the available memory without having to go 
 through any special procedures? Could I theoretically declare a really big 
 structure (iike a MB or 2) or array and be able to handle it in code like I 
 always have?
 •With the code I've written thus far, the servos are updated 128 times a 
 second. I have everything for doing that interrupt driven. I have a timer 
 fire an interrupt every 8ms that calculates the next servo target positions 
 and creates a packet to put in a buffer that feeds the shift register of 
 the serial bus. The serial bus is also interrupt driven. When the buffer is 
 loaded, an interrupt is enabled that fires whenever the shift register is 
 empty. Every time it fires, it loads the next byte from the buffer. If the 
 buffer is empty, it disables the interrupt. Receiving bytes is handled 
 similarly, firing an interrupt every time a byte is received to put it in a 
 buffer and empty the shift register. This allows the packets to be consumed 
 as quickly as the 1Mb serial bus can consume them. Could I do something 
 comparable on the BBB?
 •My third, and heaviest question, is one of the main motivators

Re: [beagleboard] Re: Whci PRU-C-compiler is recommended?

[dinuxbg]

The standard objcopy should be able to extract and convert:
  pru-objcopy -j .data myprog.elf -O binary DMEM.bin
  pru-objcopy -j .text myprog.elf -O binary IMEM.bin

Alternatively, you can parse the ELF file yourself, as does the example 
loader:  
https://github.com/dinuxbg/gnupru/blob/master/example/host/pload.c#L109

Regards,
Dimitar

21 ноември 2014, петък, 10:09:57 UTC+2, Karl Karpfen написа:

 That's cool! Is there also a tool to extract text and data binaries out of 
 an ELF file to load it into PRUs instruction and data RAM separately?

 Am Donnerstag, 20. November 2014 20:24:49 UTC+1 schrieb din...@gmail.com:

 Just to let you know that the PRU GCC toolchain also has a disassembler:
pru-objdump -d myprog.elf
 For more information do man objdump

 Regards,
 Dimitar

 19 ноември 2014, сряда, 15:25:21 UTC+2, Karl Karpfen написа:

 Meanwhile I'm more than happy with TI's C-compiler. Especially the 
 disassembler is very useful in case one has to count instructions to get 
 the exact number of clock cycles a code-sequence requires (needed in some 
 realtime applications).

 Am Donnerstag, 6. November 2014 18:40:08 UTC+1 schrieb Jason Kridner:

 On Tue, Nov 4, 2014 at 11:56 AM, Karl Karpfen karlka...@gmail.com 
 wrote: 
  OK, I'll try GCC version! Just wanted to collect some information 
 regarding 
  both compilers in this thread... 
  
  2014-11-04 17:47 GMT+01:00 din...@gmail.com: 
  
  Hi Karl, 
  
  The PRU GAS and LD ports should be in a good shape. But the PRU GCC 
 port 
  has not yet reached beta. Judge for yourself: 
  
  PRU GCC has not been battle tested on a big project. 
  Only two small examples are currently used to sanity check the pru 
 gcc 
  releases. 
  PRU GCC has no known bugs. 
  
  If you can take a little risk and don't mind checking the 
  compiler-generated assembler, then go ahead and try PRU GCC. 
  
  If you want an ASAP, no hassles C compiler for PRU, TI's one would 
 be a 
  more suitable choice right now. 
  
  Regards, 
  Dimitar 
  
  
  On Tuesday, November 4, 2014 2:11:23 PM UTC+2, Karl Karpfen wrote: 
  
  Hi, 
  
  it seems there are two C-compilers available that are able to 
 generate 
  PRU-code. One from TI and one introduced here in this board. 
 But...which one 
  is recommended to be used? That's what I found out so far, may be 
 somebody 
  can add some missing information to make it easier to choose one: 
  
  TI's PRU-C-compiler is 
  
  - available at 
  http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm 
  - BETA 
  - can be used to create ARM-objects (which can be linked to a bare 
 metal 
  application and loaded to PRU on start-up automatically?) 

 The latest version of the C compiler is no longer in beta. Even 
 better, it is a freely redistributable binary. While not as good as 
 redistributable source like the GCC, at least we can easily get it to 
 everyone; 

 http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#PRU 

 I updated the wiki page and http://beagleboard.org/pru. I expect this 
 to be included in upcoming Debian releases, if not the GCC as well. 

  
  Community/Open Source PRU-C-compiler is 
  
  - avaialble at https://github.com/dinuxbg/gnupru 
  - BETA 
  - GCC-based and therefore more stable 
  
  -- 
  For more options, visit http://beagleboard.org/discuss 
  --- 
  You received this message because you are subscribed to a topic in 
 the 
  Google Groups BeagleBoard group. 
  To unsubscribe from this topic, visit 
  
 https://groups.google.com/d/topic/beagleboard/rwNrqudk0Ug/unsubscribe. 
  To unsubscribe from this group and all its topics, send an email to 
  beagleboard...@googlegroups.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. 
  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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Whci PRU-C-compiler is recommended?

[dinuxbg]

Just to let you know that the PRU GCC toolchain also has a disassembler:
   pru-objdump -d myprog.elf
For more information do man objdump

Regards,
Dimitar

19 ноември 2014, сряда, 15:25:21 UTC+2, Karl Karpfen написа:

 Meanwhile I'm more than happy with TI's C-compiler. Especially the 
 disassembler is very useful in case one has to count instructions to get 
 the exact number of clock cycles a code-sequence requires (needed in some 
 realtime applications).

 Am Donnerstag, 6. November 2014 18:40:08 UTC+1 schrieb Jason Kridner:

 On Tue, Nov 4, 2014 at 11:56 AM, Karl Karpfen karlka...@gmail.com 
 wrote: 
  OK, I'll try GCC version! Just wanted to collect some information 
 regarding 
  both compilers in this thread... 
  
  2014-11-04 17:47 GMT+01:00 din...@gmail.com: 
  
  Hi Karl, 
  
  The PRU GAS and LD ports should be in a good shape. But the PRU GCC 
 port 
  has not yet reached beta. Judge for yourself: 
  
  PRU GCC has not been battle tested on a big project. 
  Only two small examples are currently used to sanity check the pru 
 gcc 
  releases. 
  PRU GCC has no known bugs. 
  
  If you can take a little risk and don't mind checking the 
  compiler-generated assembler, then go ahead and try PRU GCC. 
  
  If you want an ASAP, no hassles C compiler for PRU, TI's one would 
 be a 
  more suitable choice right now. 
  
  Regards, 
  Dimitar 
  
  
  On Tuesday, November 4, 2014 2:11:23 PM UTC+2, Karl Karpfen wrote: 
  
  Hi, 
  
  it seems there are two C-compilers available that are able to 
 generate 
  PRU-code. One from TI and one introduced here in this board. 
 But...which one 
  is recommended to be used? That's what I found out so far, may be 
 somebody 
  can add some missing information to make it easier to choose one: 
  
  TI's PRU-C-compiler is 
  
  - available at 
  http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm 
  - BETA 
  - can be used to create ARM-objects (which can be linked to a bare 
 metal 
  application and loaded to PRU on start-up automatically?) 

 The latest version of the C compiler is no longer in beta. Even 
 better, it is a freely redistributable binary. While not as good as 
 redistributable source like the GCC, at least we can easily get it to 
 everyone; 

 http://software-dl.ti.com/codegen/non-esd/downloads/download.htm#PRU 

 I updated the wiki page and http://beagleboard.org/pru. I expect this 
 to be included in upcoming Debian releases, if not the GCC as well. 

  
  Community/Open Source PRU-C-compiler is 
  
  - avaialble at https://github.com/dinuxbg/gnupru 
  - BETA 
  - GCC-based and therefore more stable 
  
  -- 
  For more options, visit http://beagleboard.org/discuss 
  --- 
  You received this message because you are subscribed to a topic in the 
  Google Groups BeagleBoard group. 
  To unsubscribe from this topic, visit 
  https://groups.google.com/d/topic/beagleboard/rwNrqudk0Ug/unsubscribe. 

  To unsubscribe from this group and all its topics, send an email to 
  beagleboard...@googlegroups.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. 
  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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Whci PRU-C-compiler is recommended?

[dinuxbg]

Hi Karl,

The PRU GAS and LD ports should be in a good shape. But the PRU GCC port 
has not yet reached beta. Judge for yourself:

   - PRU GCC has not been battle tested on a big project.
   - Only two small examples are currently used to sanity check the pru 
   gcc releases.
   - PRU GCC has no known bugs.

If you can take a little risk and don't mind checking the 
compiler-generated assembler, then go ahead and try PRU GCC.

If you want an ASAP, no hassles C compiler for PRU, TI's one would be a 
more suitable choice right now.

Regards,
Dimitar

On Tuesday, November 4, 2014 2:11:23 PM UTC+2, Karl Karpfen wrote:

 Hi,

 it seems there are two C-compilers available that are able to generate 
 PRU-code. One from TI and one introduced here in this board. But...which 
 one is recommended to be used? That's what I found out so far, may be 
 somebody can add some missing information to make it easier to choose one:

 TI's PRU-C-compiler is

 - available at 
 http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm
 - BETA
 - can be used to create ARM-objects (which can be linked to a bare metal 
 application and loaded to PRU on start-up automatically?)

 Community/Open Source PRU-C-compiler is

 - avaialble at https://github.com/dinuxbg/gnupru
 - BETA
 - GCC-based and therefore more stable



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GNU GCC C compiler for PRU

[dinuxbg]

The MD5 example has been fixed. I had forgotten to update binutils after 
changing the Return Address register number.

I started taking notes for the new calling convention on 
https://github.com/dinuxbg/gnupru/wiki . I'll wait a couple of weeks to 
gather comments before commencing with the implementation.

Regards,
Dimitar 

On Wednesday, June 18, 2014 3:15:20 PM UTC+3, Jason Kridner wrote:



 On Monday, June 16, 2014 4:34:58 PM UTC-4, jmelson wrote:



 On Monday, June 16, 2014 1:01:05 PM UTC-5, Jason Kridner wrote:


 (TSPA means no EULA ahead of download, just a download. This next big 
 release would likely be toward the end of next year. The wiki in 
 discussion is http://processors.wiki.ti.com) 


 end of ** 2015 ** ???  The chip will likely be obsolete by then!  Yikes, 
 why
 such a huge delay?

 Not that I really think this is such a catastrophe, it is not so bad to 
 do very
 low-level tasks in the PRU assembler, where you are totally conscious of
 every machine cycle.

 Jon 


 The C compiler is already publicly available (
 http://elinux.org/Ti_AM33XX_PRUSSv2#C_Compiler), just currently requires 
 a EULA. The documentation required for sharing the calling conventions, 
 however, should be posted much sooner. 


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GNU GCC C compiler for PRU

[dinuxbg]

Jason, I reproduced your error by switching to bash as default shell. On my 
debian PC the default dash shell silently drops the error code from the 
failed source command. I'm working on a fix.

On Thursday, June 12, 2014 2:14:46 AM UTC+3, Jason Kridner wrote:

 On Sun, Apr 20, 2014 at 2:49 AM,  din...@gmail.com javascript: wrote: 
  I'd like to announce my hobby project for the past few months - a port 
 of 
  GNU GCC and Binutils to TI's PRU. Patches and a simple example can be 
  downloaded from https://github.com/dinuxbg/gnupru . 
  
  Please note that this is still a work in progress. But since now there 
 is a 
  working blinking led example, I decided others may be interested. 
  
  Disclaimers: 
   1. This effort has no relation to the rumored TI C PRU compiler. 
   2. This is a preliminary release, so expect bugs. If your program 
 doesn't 
  run, then please be prepared to disassemble and check what the 
  compiler/assembler/linker did. 
   3. There is no C library. 
   4. ABI is not yet finalized. 

 Tried building it on a Mac. Not sure if you are interested, but here's 
 the last bit of the error I got when making a quick pass (clone and 
 run build.sh): 

 . 
 . 
 . 
 gcc -DHAVE_CONFIG_H -I. 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld  -I. 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld -I../bfd 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld/../bfd 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld/../include  -g -O2 
 -DENABLE_PLUGINS 
 -DLOCALEDIR=\/Users/jason/bin/pru-gcc/share/locale\  -W -Wall 
 -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT 
 ldlex-wrapper.o -MD -MP -MF .deps/ldlex-wrapper.Tpo -c -o 
 ldlex-wrapper.o 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/ldlex-wrapper.c 
 -Wno-error 
 libtool: link: gcc -dynamiclib  -o .libs/libldtestplug.0.dylib 
 .libs/libldtestplug_la-testplug.o   -lz  -Wl,-no_pie   -install_name 
 /nowhere/libldtestplug.0.dylib -compatibility_version 1 
 -current_version 1.0 -Wl,-single_module 
 mv -f .deps/ldlang.Tpo .deps/ldlang.Po 
 LIB_PATH='' /bin/sh 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/genscripts.sh 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld 
 /Users/jason/bin/pru-gcc/lib /Users/jason/bin/pru-gcc 
 /Users/jason/bin/pru-gcc x86_64-apple-darwin12.5.0 pru-unknown-none 
 pru pruelf /usr/local/lib /lib /usr/lib no no pruelf pru 
 libtool: link: (cd .libs  rm -f libldtestplug.dylib  ln -s 
 libldtestplug.0.dylib libldtestplug.dylib) 
 libtool: link: ar rc .libs/libldtestplug.a  libldtestplug_la-testplug.o 
 libtool: link: ranlib .libs/libldtestplug.a 
 In file included from 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/ldlex-wrapper.c:26: 
 ldlex.c: In function ‘yy_scan_buffer’: 
 ldlex.c:3822: warning: declaration of ‘base’ shadows a global declaration 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/ldlang.h:508: 
 warning: shadowed declaration is here 
 libtool: link: ( cd .libs  rm -f libldtestplug.la  ln -s 
 ../libldtestplug.la libldtestplug.la ) 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/genscrba.sh: line 6: 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/emultempl/pruelf.em: 
 No such file or directory 
 make[4]: *** [epruelf.c] Error 1 
 make[4]: *** Waiting for unfinished jobs 
 rm -f ld.pod 
 mv -f .deps/ldlex-wrapper.Tpo .deps/ldlex-wrapper.Po 
 make[3]: *** [all-recursive] Error 1 
 make[2]: *** [all] Error 2 
 make[1]: *** [all-ld] Error 2 
 make: *** [all] Error 2 


 I'll try again on an ARM/Linux board next, but the Mac was handy at 
 the time. Might look a bit more at where pruelf.em gets created, but 
 didn't know if it might simply be missing from the patch as the other 
 .em files all seem to be under source control and not generated. 

  
  Regards, 
  Dimitar 
  
  -- 
  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 javascript:. 
  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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GNU GCC C compiler for PRU

[dinuxbg]

I pushed the build fix to the master branch. You should now be able to 
build your toolchain, make the LED example, and see the blinking led.

Now the bad news. I tried a bit more complex example but it failed (see the 
md5-example branch on github). I'm on to chasing why MD5 generation differs 
between ARM and x86_64 hosts on one hand and PRU target on the other hand.

Regarding the ABI. I tried to download TI's compiler to see its readme, but 
it asked for registration and accepting some EULA. I'd rather not spend my 
free time reading legalese, so until I see TI's ABI description in an open 
Wiki, it remains secret to me :)

I'll try to propose a GCC PRU ABI in the next couple of days. I'm very keen 
to hear comments from community.

Regards,
Dimitar

On Sunday, June 15, 2014 9:16:34 AM UTC+3, din...@gmail.com wrote:

 Jason, I reproduced your error by switching to bash as default shell. On 
 my debian PC the default dash shell silently drops the error code from 
 the failed source command. I'm working on a fix.

 On Thursday, June 12, 2014 2:14:46 AM UTC+3, Jason Kridner wrote:

 On Sun, Apr 20, 2014 at 2:49 AM,  din...@gmail.com wrote: 
  I'd like to announce my hobby project for the past few months - a port 
 of 
  GNU GCC and Binutils to TI's PRU. Patches and a simple example can be 
  downloaded from https://github.com/dinuxbg/gnupru . 
  
  Please note that this is still a work in progress. But since now there 
 is a 
  working blinking led example, I decided others may be interested. 
  
  Disclaimers: 
   1. This effort has no relation to the rumored TI C PRU compiler. 
   2. This is a preliminary release, so expect bugs. If your program 
 doesn't 
  run, then please be prepared to disassemble and check what the 
  compiler/assembler/linker did. 
   3. There is no C library. 
   4. ABI is not yet finalized. 

 Tried building it on a Mac. Not sure if you are interested, but here's 
 the last bit of the error I got when making a quick pass (clone and 
 run build.sh): 

 . 
 . 
 . 
 gcc -DHAVE_CONFIG_H -I. 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld  -I. 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld -I../bfd 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld/../bfd 
 -I/Users/jason/workspace/gnupru/src/binutils-gdb/ld/../include  -g -O2 
 -DENABLE_PLUGINS 
 -DLOCALEDIR=\/Users/jason/bin/pru-gcc/share/locale\  -W -Wall 
 -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT 
 ldlex-wrapper.o -MD -MP -MF .deps/ldlex-wrapper.Tpo -c -o 
 ldlex-wrapper.o 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/ldlex-wrapper.c 
 -Wno-error 
 libtool: link: gcc -dynamiclib  -o .libs/libldtestplug.0.dylib 
 .libs/libldtestplug_la-testplug.o   -lz  -Wl,-no_pie   -install_name 
 /nowhere/libldtestplug.0.dylib -compatibility_version 1 
 -current_version 1.0 -Wl,-single_module 
 mv -f .deps/ldlang.Tpo .deps/ldlang.Po 
 LIB_PATH='' /bin/sh 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/genscripts.sh 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld 
 /Users/jason/bin/pru-gcc/lib /Users/jason/bin/pru-gcc 
 /Users/jason/bin/pru-gcc x86_64-apple-darwin12.5.0 pru-unknown-none 
 pru pruelf /usr/local/lib /lib /usr/lib no no pruelf pru 
 libtool: link: (cd .libs  rm -f libldtestplug.dylib  ln -s 
 libldtestplug.0.dylib libldtestplug.dylib) 
 libtool: link: ar rc .libs/libldtestplug.a  libldtestplug_la-testplug.o 
 libtool: link: ranlib .libs/libldtestplug.a 
 In file included from 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/ldlex-wrapper.c:26: 
 ldlex.c: In function ‘yy_scan_buffer’: 
 ldlex.c:3822: warning: declaration of ‘base’ shadows a global declaration 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/ldlang.h:508: 
 warning: shadowed declaration is here 
 libtool: link: ( cd .libs  rm -f libldtestplug.la  ln -s 
 ../libldtestplug.la libldtestplug.la ) 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/genscrba.sh: line 6: 
 /Users/jason/workspace/gnupru/src/binutils-gdb/ld/emultempl/pruelf.em: 
 No such file or directory 
 make[4]: *** [epruelf.c] Error 1 
 make[4]: *** Waiting for unfinished jobs 
 rm -f ld.pod 
 mv -f .deps/ldlex-wrapper.Tpo .deps/ldlex-wrapper.Po 
 make[3]: *** [all-recursive] Error 1 
 make[2]: *** [all] Error 2 
 make[1]: *** [all-ld] Error 2 
 make: *** [all] Error 2 


 I'll try again on an ARM/Linux board next, but the Mac was handy at 
 the time. Might look a bit more at where pruelf.em gets created, but 
 didn't know if it might simply be missing from the patch as the other 
 .em files all seem to be under source control and not generated. 

  
  Regards, 
  Dimitar 
  
  -- 
  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. 
  For more options, visit https://groups.google.com/d/optout

Re: [beagleboard] GNU GCC C compiler for PRU

[dinuxbg]

I couldn't find a description of TI's PRU C ABI. Can somebody help by 
publicly posting it?

If TI PRU C ABI turns out to be secret, then what do you think GCC PRU ABI 
should look like?

Thanks,
Dimitar

On Wednesday, May 21, 2014 9:27:17 PM UTC+3, din...@gmail.com wrote:


 On Wednesday, May 21, 2014 2:50:52 PM UTC+3, Jason Kridner wrote:



 On Sunday, April 20, 2014, din...@gmail.com wrote:

 I'd like to announce my hobby project for the past few months - a port 
 of GNU GCC and Binutils to TI's PRU. Patches and a simple example can be 
 downloaded from https://github.com/dinuxbg/gnupru .

 Please note that this is still a work in progress. But since now there 
 is a working blinking led example, I decided others may be interested.


 Thank you, thank you!
  




 Disclaimers:
  1. This effort has no relation to the rumored TI C PRU compiler. 

  

 Said rumored compiler is at 
 http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm
  


  2. This is a preliminary release, so expect bugs. If your program 
 doesn't run, then please be prepared to disassemble and check what the 
 compiler/assembler/linker did.
  3. There is no C library.
  4. ABI is not yet finalized.


 If you can make the ABI compatible, that would be really cool. 

 Can you share this compatible ABI? If I have the specification and it is 
 easy to modify GCC, then I could do it. I'll have to change the ABI anyway 
 - current one is not optimal for using the hardware multiplication 
 instruction.

 FYI, the current GCC PRU ABI was inspired by Nios2 and looks roughly like 
 this:
Regno  Name
0-3r0-r3Register Arguments. Rest of arguments are saved 
 on stack.
4-5r4-r5Return Location. Allows 64bit value return 
 without involving the stack.
6-16   r6-r16   Caller Saved Registers
17-26  r17-r26  Callee Saved Registers
27 r27  ra  Return Address
28 r28  sp  Stack Pointer
29 r29  fp  Frame Pointer. Usually omitted and used as a 
 general-purpose register.
30 r30  Special I/O register. Not used by compiler.
31 r31  Special I/O register. Not used by compiler.


  



 Regards,
 Dimitar



  

  

  -- 
 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.
 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GNU GCC C compiler for PRU

[dinuxbg]

On Wednesday, May 21, 2014 2:50:52 PM UTC+3, Jason Kridner wrote:



 On Sunday, April 20, 2014, din...@gmail.com javascript: wrote:

 I'd like to announce my hobby project for the past few months - a port of 
 GNU GCC and Binutils to TI's PRU. Patches and a simple example can be 
 downloaded from https://github.com/dinuxbg/gnupru .

 Please note that this is still a work in progress. But since now there is 
 a working blinking led example, I decided others may be interested.


 Thank you, thank you!
  




 Disclaimers:
  1. This effort has no relation to the rumored TI C PRU compiler. 

  

 Said rumored compiler is at 
 http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm
  


  2. This is a preliminary release, so expect bugs. If your program 
 doesn't run, then please be prepared to disassemble and check what the 
 compiler/assembler/linker did.
  3. There is no C library.
  4. ABI is not yet finalized.


 If you can make the ABI compatible, that would be really cool. 

Can you share this compatible ABI? If I have the specification and it is 
easy to modify GCC, then I could do it. I'll have to change the ABI anyway 
- current one is not optimal for using the hardware multiplication 
instruction.

FYI, the current GCC PRU ABI was inspired by Nios2 and looks roughly like 
this:
   Regno  Name
   0-3r0-r3Register Arguments. Rest of arguments are saved 
on stack.
   4-5r4-r5Return Location. Allows 64bit value return 
without involving the stack.
   6-16   r6-r16   Caller Saved Registers
   17-26  r17-r26  Callee Saved Registers
   27 r27  ra  Return Address
   28 r28  sp  Stack Pointer
   29 r29  fp  Frame Pointer. Usually omitted and used as a 
general-purpose register.
   30 r30  Special I/O register. Not used by compiler.
   31 r31  Special I/O register. Not used by compiler.


 



 Regards,
 Dimitar



  

  

  -- 
 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.
 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] GNU GCC port for PRU in the works

[dinuxbg]

I'd like to announce a hobby project of mine - port of GCC and Binutils to 
PRU: https://github.com/dinuxbg/gnupru https://github.com/dinuxbg/gnupru

It is still very much work-in-progress. But since I managed to build a 
working blinking led demo, I decided some may be interested in it.

Disclaimers:
 1. This effort is completely unrelated to the rumored TI PRU C compiler.
 2. There are probably many bugs. If something doesn't work, then please be 
prepared to disassemble and even check the machine binary opcodes.
 3. There is no C library.
 4. ABI is still not finalized, hence the lack of documentation.

Happy hacking,
Dimitar

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] GNU GCC C compiler for PRU

[dinuxbg]

I'd like to announce my hobby project for the past few months - a port of 
GNU GCC and Binutils to TI's PRU. Patches and a simple example can be 
downloaded from https://github.com/dinuxbg/gnupru .

Please note that this is still a work in progress. But since now there is a 
working blinking led example, I decided others may be interested.

Disclaimers:
 1. This effort has no relation to the rumored TI C PRU compiler.
 2. This is a preliminary release, so expect bugs. If your program doesn't 
run, then please be prepared to disassemble and check what the 
compiler/assembler/linker did.
 3. There is no C library.
 4. ABI is not yet finalized.

Regards,
Dimitar

-- 
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.
For more options, visit https://groups.google.com/d/optout.