John, make your own post and post there.
On Mon, Dec 14, 2015 at 2:27 AM, William Hermans wrote:
> *Is there a new branch of the am335x_pru_package using remoteproc that
>> I've missed? alternatively does anyone know what i would have to include to
>> get uio back up and running again without ch
>
> *Is there a new branch of the am335x_pru_package using remoteproc that
> I've missed? alternatively does anyone know what i would have to include to
> get uio back up and running again without changing kernels? I'm trying to
> keep my software package as a fairly simple install that runs on all
William, you are over thinking this. It isn’t that complicated. If you don’t
want to take the time to learn something new, then don’t, but don’t bad mouth
something you don’t understand. There are enough examples and documentation out
there if you only take the time to look, which is the advise
interesting. Looks like the latest beaglebone stable image (2015-11-12
jessie) has the "ti" kernel, not a "bone" kernel. This explains why so many
things don't load for me.
root@beaglebone:~# uname -r
4.1.12-ti-r29
root@beaglebone:/sys/class/uio# cat /etc/dogtag
BeagleBoard.org Debian Image 201
On Sun, 13 Dec 2015 17:22:43 -0700, you wrote:
>I actually think remoteproc / rpmsg is usefu for multi core systems. Say a
>dual core ARM processor where one core is running Linux, and the other is
>running bare metal for deterministic purpose. I am however still
>unconvinced how it is useful whe
Robert, By the way, there is only one remoteproc / rpmsg example there. The
rest is either uio based, or completely non relevant( demonstrating some
"new" gcc feature ).
On Sun, Dec 13, 2015 at 5:33 PM, William Hermans wrote:
> . . . And my god, what is this supposed to be ? C ?
>
>
> https://gi
. . . And my god, what is this supposed to be ? C ?
https://github.com/dinuxbg/pru-gcc-examples/blob/master/blinking-led/pru/resource_table_0.h#L43-L72
On Sun, Dec 13, 2015 at 5:22 PM, William Hermans wrote:
> I actually think remoteproc / rpmsg is usefu for multi core systems. Say a
> dual cor
I actually think remoteproc / rpmsg is usefu for multi core systems. Say a
dual core ARM processor where one core is running Linux, and the other is
running bare metal for deterministic purpose. I am however still
unconvinced how it is useful when you have multiple cores on die that are
not all ap
It's a BS example because it does not illustrate how remoteproc and rpmsg
are useful. It also does not illustrate how to access the hardware modules
through this technology. Here . . .
Something useful -> https://github.com/boxysean/beaglebone-DMX
Something else useful -> https://github.com/pgmmpk
How is that a BS example? The example shows an ARM kernel module sending a
message to the PRU, which interrupts the PRU, which then copies the message
from the PRU rx buffer to the PRU tx buffer, which then executes a callback on
the ARM kernel module. You should be able to take that code and ma
On Sun, Dec 13, 2015 at 5:19 PM, William Hermans wrote:
> OK, so show us a real world example of rpmsg.
>
Some good ones here:
https://github.com/dinuxbg/pru-gcc-examples
all using binutils/gcc. ;)
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
For more options, visit http://beagleboard
By real world I mean a real world useful example. Not some BS spit 100
"hello" messages out into dmesg.
On Sun, Dec 13, 2015 at 4:19 PM, William Hermans wrote:
> OK, so show us a real world example of rpmsg.
>
> On Sun, Dec 13, 2015 at 3:53 PM, John Syne wrote:
>
>> OK, so maybe you can explain
OK, so show us a real world example of rpmsg.
On Sun, Dec 13, 2015 at 3:53 PM, John Syne wrote:
> OK, so maybe you can explain why you think there is a difference between
> writing PRU firmware targeting PRUSS vs PRU firmware targeting remoteproc?
> The only difference is the API. You can build
OK, so maybe you can explain why you think there is a difference between
writing PRU firmware targeting PRUSS vs PRU firmware targeting remoteproc? The
only difference is the API. You can build the firmware for each in the same
way. The only reference to CCSV6 is the examples TI created for remo
We're not talking about the X15 in this post, and personally, I probably
won't be using an X15 for a long, long time. Too much board, for too much
money.
On Sun, Dec 13, 2015 at 1:30 PM, John Syne wrote:
> Remoteproc/RPMSG is a standard in mainline for interfacing ARM to other
> processors on th
Remoteproc/RPMSG is a standard in mainline for interfacing ARM to other
processors on the same SOC. On the x15, this will be the only way you can
interface to the DSP, M4’s, etc. Other vendors have adopted this solutions as
well.
Regards,
John
> On Dec 13, 2015, at 12:25 PM, William Herman
Well, bone is far behind the ti kernel. When I added remote-proc to the bone
kernel, the patch was very large. With the ti kernel, most of the patches where
already applied. Anyway, I did send Robert the bone patches, but he decided not
to apply them.
Regards,
John
> On Dec 13, 2015, at 12
So, not to argue, but my point of view. I have no problem with people using
remoteproc, *if* that's what they want to do. At the same time, I feel that
it should not be "forced down our throats", because right now, it is not
ready for prime time. uio_pruss is a known quantity, lots of people have
d
>
> *With newer kernels, you need to use the standard Linux remote-proc*
> * interface, rather than the legacy UIO driver.*
Not exactly. Only if you're using the *TI kernels. The *bone kernels have
uio_pruss enabled.
william@beaglebone:~$ *uname -r*
4.1.12-bone-rt-r16
william@beaglebone:~$ *sud
On 12/13/2015 4:37 AM, Strawson wrote:
> Sadly I'm running into the same missing uio directories now that I'm trying
> to get my beaglebone code that was stable on the 3.8 kernel and Wheezy
> image. My old compiled dtbo wouldn't load with a 4.1 kernel until it was
> recompiled. Even with it load
Robert Nelson told us that the uio pruss is not working on the kernel ti.
If you want to have uio pruss you should use the bb kernel.
https://github.com/RobertCNelson/bb-kernel
It's because Texas is working on a new pruss driver.
Le dim. 13 déc. 2015 11:37, Strawson a écrit :
> Sadly I'm runni
Sadly I'm running into the same missing uio directories now that I'm trying
to get my beaglebone code that was stable on the 3.8 kernel and Wheezy
image. My old compiled dtbo wouldn't load with a 4.1 kernel until it was
recompiled. Even with it loaded, the following modules don't load: PRU,
eQE
my bad, I missed a necessary point there. Basically you need to change
status = "disabled"; to status = "okay";
Then it is my best guess that everything you need to use uio_pruss will be
loaded correctly.
On Tue, Nov 10, 2015 at 5:17 PM, William Hermans wrote:
> So a bit more information. Here
So a bit more information. Here is the device tree overlay i've loaded
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
/* identification */
part-number = "pruss_enable";
version = "00A0";
fragment@0 {
target = <&pruss>;
I've just started learning about uio myself, but my guess is that you've
loaded the uio_pruss module manually. Yes ? So with a kernel that has cape
manager . . .
$ uname -r
4.1.9-bone-rt-r16
$ lsmod |grep pru
$ sudo sh -c "echo 'pru_enable' > /sys/devices/platform/bone_capemgr/slots"
$ lsmod |gre
I've got a slight issue--
On my hardware:
root@localhost:/sys/class/uio# uname -r
3.14.54-ti-rt-r77
root@localhost:/sys/class/uio# lsmod
Module Size Used by
usb_f_ecm 7909 1
g_ether 1802 0
usb_f_rndis17719 2 g_ether
u_ether
26 matches
Mail list logo
