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,
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
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
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,
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
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 Tu
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.wik
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
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
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
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
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
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
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
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"
t;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/ov
probe 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
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
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
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)
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
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,
>
> *Th
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
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:
>
>
-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
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/b
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 ( *
es 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>).
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 somethi
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
-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
/
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
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 юни
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
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
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
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
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
, 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
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
, 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
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
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
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
44 matches
Mail list logo
