Re: [beagleboard] Re: PRU Assumptions - True or False

['Mark Lazarewicz' via BeagleBoard]

Hello AMF 
I have 5 year old quad core win 8.1 64 bit 8 G ram laptop running Ubuntu 16.04 
VM  I used it to build SDK kernel no problems and 
a new Debian 10 VM with a 64 bit GCC on same machine. The Debian VM is flaky 
last attempt  I just got memory calloc error on building 5.5 TI BSP from the 
instructions on Digikey.


I have a 10 year old win 7 quad core desktop I think it has 8 gig ram I never 
used I was contemplating either a dual boot or nuke win 7 a native Linux build 
box. Problem is it's probably 32 bit.
Which compiler are you using? 32 bit or 64 bit and a link to it would be great 
and Is this 5.x or 5.x 
I have several BBW, an am335x SK and two BBB for hardware. I'm also a JTAG user 
so I'd prefer nothing in EMC I don't know if that's possible?
I also probably need SD preparation instructions to go with kernel.
You know something like Robert has and the SDK has that even a college student 
can follow
Thanks alot!!
Mark


Sent from Yahoo Mail on Android 
 
  On Sun, May 30, 2021 at 11:02 AM, amf wrote:   Hi 
lazarman,on ubuntu 20.04, this builds ok
git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
cd ti-linux-kernel-dev
git checkout remotes/origin/ti-linux-rt-5.4.y -b ti-linux-rt-5.4.y
./build_kernel.sh

I've used VirtualBox before with Ubuntu 16/18/20 without any issues, what VM 
are you using?Several years ago a company that I worked for used some other VM, 
it was a pain in the azz to get to work, if i hear the name again i'll know if 
that was the one.I haven't used Debian for a desktop, so I can't help you with 
that. 

On Saturday, May 29, 2021 at 3:45:46 PM UTC-5 lazarman wrote:

 Hello 
I've failed to build following those instructions twice in Mainline  and twice 
using the TI BSP.version. the 2nd attempt of TI BSP is hung as we speak after 
resolving dependencies for several hours. Each attempt takes hours and the 
build_kernel script doesnt care you already cloned 2G of code it clones 
torvald.gitso I retried 4 times by running build_kernel.sh twice in both 
directories
The Mainline had some git branch errors today
I paid to upgrade my internet for this testing and was ready to buy a 64 bit 
box but am scared these instructions need a refresh and I will waste $$
what would be lovely is a 2 line like is in the instruction pasted below with 
something that will work for sure.the two directories I created are both on 
wrong branches and  dont complete a buil d
Be nice not keep downloading the 2G kernel source I know there is  a rebuild.sh 
but I am assuming that is used after a successful buildIf these instruction 
need I tweek I can understand I can test them. If it old and not supported a 
heads up would be appreciated. So I need something like this below with 
everything needed to build a kernel including the previous two steps as my two 
directories are on the wrong branches
Thanks

For TI v5.4.x: Real-Time#~/ti-linux-kernel-dev/
git checkout origin/ti-linux-rt-5.4.y -b tmp


Build:




Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s


Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s

Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.sh



On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson 
 wrote:  
 
 On Fri, May 28, 2021 at 2:53 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 2:45 PM Robert Nelson  wrote:
> >
> > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz  wrote:
> > >
> > > Thanks!!
> > >
> > > Think of it as I'm validating the instructions I think having these is 
> > > something good. Unfortunately my VM blew up just now.
> > >
> > > I KNOW your adamant about not supporting VM.
> > >
> > > So I'll build a dedicated Debian 8 dev box.
> > >
> > > Any hints tips lessons learned what you use be appreciated.
> > >
> > > Have a great long weekend.
> >
> > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
> > failure point..
>
> I think mainline might work:
>
> debian@beaglebone:~$ uname -r
> 5.13.0-rc3-bone2.2
> debian@beaglebone:~$ dmesg | grep pru
> [    2.044506] remoteproc remoteproc1: 4a334000.pru is available
> [    2.045701] remoteproc remoteproc2: 4a338000.pru is available
> debian@beaglebone:~$ ls /dev/remoteproc/pruss-core*
> /dev/remoteproc/pruss-core0:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> /dev/remoteproc/pruss-core1:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> @Mark Yoder can you test? ;)

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state
[  243.355728] remoteproc remoteproc1: powering up 4a334000.pru
[  243.366533] remoteproc remoteproc1: Booting fw image
am335x-pru0-fw, size 32456
[  243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state
[  296.981371] remoteproc remoteproc1: stopped remote processor 4a334000.pru

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
  


-- 
For more options, 

Re: [beagleboard] Re: PRU Assumptions - True or False

[amf]

Hi lazarman,
on ubuntu 20.04, this builds ok

git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
cd ti-linux-kernel-dev
git checkout remotes/origin/ti-linux-rt-5.4.y -b ti-linux-rt-5.4.y
./build_kernel.sh

I've used VirtualBox before with Ubuntu 16/18/20 without any issues, what 
VM are you using?
Several years ago a company that I worked for used some other VM, it was a 
pain in the azz to get to work, if i hear the name again i'll know if that 
was the one.
I haven't used Debian for a desktop, so I can't help you with that. 

On Saturday, May 29, 2021 at 3:45:46 PM UTC-5 lazarman wrote:

> Hello 
>
> I've failed to build following those instructions twice in Mainline  and 
> twice using the TI BSP.version. the 2nd attempt of TI BSP is hung as we 
> speak after resolving dependencies for several hours. Each attempt takes 
> hours and the build_kernel script doesnt care you already cloned 2G of code 
> it clones torvald.git
> so I retried 4 times by running build_kernel.sh twice in both directories
>
> The Mainline had some git branch errors today
>
> I paid to upgrade my internet for this testing and was ready to buy a 64 
> bit box but am scared these instructions need a refresh and I will waste $$
>
> what would be lovely is a 2 line like is in the instruction pasted below 
> with something that will work for sure.
> the two directories I created are both on wrong branches and  dont 
> complete a buil d
>
> Be nice not keep downloading the 2G kernel source I know there is  a 
> rebuild.sh but I am assuming that is used after a successful build
> If these instruction need I tweek I can understand I can test them. If it 
> old and not supported a heads up would be appreciated. So I need something 
> like this below with everything needed to build a kernel including the 
> previous two steps as my two directories are on the wrong branches
>
> Thanks
>
>
> For TI v5.4.x: Real-Time
>
> #~/ti-linux-kernel-dev/
> git checkout origin/ti-linux-rt-5.4.y -b tmp
>
> Build:
>
>
>
>
> Build:
>
> #user@localhost:~/ti-linux-kernel-dev$
> ./build_kernel.s
>
>
>
> Build:
>
> #user@localhost:~/ti-linux-kernel-dev$
> ./build_kernel.s
>
>
> Build:
>
> #user@localhost:~/ti-linux-kernel-dev$
> ./build_kernel.sh
>
>
>
>
>
> On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson <
> robert...@gmail.com> wrote: 
>
>
> On Fri, May 28, 2021 at 2:53 PM Robert Nelson  wrote:
> >
> > On Fri, May 28, 2021 at 2:45 PM Robert Nelson  
> wrote:
> > >
> > > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz  
> wrote:
> > > >
> > > > Thanks!!
> > > >
> > > > Think of it as I'm validating the instructions I think having these 
> is something good. Unfortunately my VM blew up just now.
> > > >
> > > > I KNOW your adamant about not supporting VM.
> > > >
> > > > So I'll build a dedicated Debian 8 dev box.
> > > >
> > > > Any hints tips lessons learned what you use be appreciated.
> > > >
> > > > Have a great long weekend.
> > >
> > > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
> > > failure point..
> >
> > I think mainline might work:
> >
> > debian@beaglebone:~$ uname -r
> > 5.13.0-rc3-bone2.2
> > debian@beaglebone:~$ dmesg | grep pru
> > [2.044506] remoteproc remoteproc1: 4a334000.pru is available
> > [2.045701] remoteproc remoteproc2: 4a338000.pru is available
> > debian@beaglebone:~$ ls /dev/remoteproc/pruss-core*
> > /dev/remoteproc/pruss-core0:
> > coredump  device  firmware  name  power  recovery  state  subsystem  
> uevent
> >
> > /dev/remoteproc/pruss-core1:
> > coredump  device  firmware  name  power  recovery  state  subsystem  
> uevent
> >
> > @Mark Yoder can you test? ;)
>
> debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state
> [  243.355728] remoteproc remoteproc1: powering up 4a334000.pru
> [  243.366533] remoteproc remoteproc1: Booting fw image
> am335x-pru0-fw, size 32456
> [  243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is 
> now up
>
> debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state
> [  296.981371] remoteproc remoteproc1: stopped remote processor 
> 4a334000.pru
>
>
> 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/6dcb2683-2d69-45fa-a4a8-62bb6c6e3ed0n%40googlegroups.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

> Be nice not keep downloading the 2G kernel source I know there is  a 
> rebuild.sh but I am assuming that is used after a successful build
> If these instruction need I tweek I can understand I can test them. If it old 
> and not supported a heads up would be appreciated. So I need something like 
> this below with everything needed to build a kernel including the previous 
> two steps as my two directories are on the wrong branches

There is a variable in system.sh to set this up, most users use it
once and done..

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-5.4.y/system.sh.sample

```
###OPTIONAL: LINUX_GIT: specify location of locally cloned git tree.
#
#LINUX_GIT=/home/user/linux-stable/
```

Anywhere in your root file system, clone Torvald's tree:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

and set LINUX_GIT variable to it's location:

For example in home:

cd /home//repos/
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Then set in system.sh
LINUX_GIT=/home//repos/linux/

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/CAOCHtYjWo%3DTrXqp04tkMA31O_fQ%2BJr_SFRz7hDZ_jGw49OS1qA%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

['Mark Lazarewicz' via BeagleBoard]

 I decided to make another attempt a clean dir on Mainline 5.4 I was blocked. 
No password . That was not there before 
I guess I will take a break

Linux Kernel

This script will build the kernel, modules, device tree binaries and copy them 
to the deploy directory.

Mainline


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Debian: Getting Started with the BeagleBone Black

This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability 
Boards: BeagleBone Black at Digi-K...
 |

 |

 |




Download:
#~/
git clone https://github.com/RobertCNelson/bb-kernel
cd bb-kernel/

On Saturday, May 29, 2021, 03:52:25 PM CDT, 'Mark Lazarewicz' via 
BeagleBoard  wrote:  
 
  Hello 
I've failed to build following those instructions twice in Mainline  and twice 
using the TI BSP.version. the 2nd attempt of TI BSP is hung as we speak after 
resolving dependencies for several hours. Each attempt takes hours and the 
build_kernel script doesnt care you already cloned 2G of code it clones 
torvald.gitso I retried 4 times by running build_kernel.sh twice in both 
directories
The Mainline had some git branch errors today
I paid to upgrade my internet for this testing and was ready to buy a 64 bit 
box but am scared these instructions need a refresh and I will waste $$
what would be lovely is a 2 line like is in the instruction pasted below with 
something that will work for sure.the two directories I created are both on 
wrong branches and  dont complete a buil d
Be nice not keep downloading the 2G kernel source I know there is  a rebuild.sh 
but I am assuming that is used after a successful buildIf these instruction 
need I tweek I can understand I can test them. If it old and not supported a 
heads up would be appreciated. So I need something like this below with 
everything needed to build a kernel including the previous two steps as my two 
directories are on the wrong branches
Thanks

For TI v5.4.x: Real-Time#~/ti-linux-kernel-dev/
git checkout origin/ti-linux-rt-5.4.y -b tmp


Build:




Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s


Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s

Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.sh



On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson 
 wrote:  
 
 On Fri, May 28, 2021 at 2:53 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 2:45 PM Robert Nelson  wrote:
> >
> > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz  wrote:
> > >
> > > Thanks!!
> > >
> > > Think of it as I'm validating the instructions I think having these is 
> > > something good. Unfortunately my VM blew up just now.
> > >
> > > I KNOW your adamant about not supporting VM.
> > >
> > > So I'll build a dedicated Debian 8 dev box.
> > >
> > > Any hints tips lessons learned what you use be appreciated.
> > >
> > > Have a great long weekend.
> >
> > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
> > failure point..
>
> I think mainline might work:
>
> debian@beaglebone:~$ uname -r
> 5.13.0-rc3-bone2.2
> debian@beaglebone:~$ dmesg | grep pru
> [    2.044506] remoteproc remoteproc1: 4a334000.pru is available
> [    2.045701] remoteproc remoteproc2: 4a338000.pru is available
> debian@beaglebone:~$ ls /dev/remoteproc/pruss-core*
> /dev/remoteproc/pruss-core0:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> /dev/remoteproc/pruss-core1:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> @Mark Yoder can you test? ;)

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state
[  243.355728] remoteproc remoteproc1: powering up 4a334000.pru
[  243.366533] remoteproc remoteproc1: Booting fw image
am335x-pru0-fw, size 32456
[  243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state
[  296.981371] remoteproc remoteproc1: stopped remote processor 4a334000.pru

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/1419458740.838013.1622321132117%40mail.yahoo.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/1798894309.849361.1622330593235%40mail.yahoo.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

['Mark Lazarewicz' via BeagleBoard]

 Hello 
I've failed to build following those instructions twice in Mainline  and twice 
using the TI BSP.version. the 2nd attempt of TI BSP is hung as we speak after 
resolving dependencies for several hours. Each attempt takes hours and the 
build_kernel script doesnt care you already cloned 2G of code it clones 
torvald.gitso I retried 4 times by running build_kernel.sh twice in both 
directories
The Mainline had some git branch errors today
I paid to upgrade my internet for this testing and was ready to buy a 64 bit 
box but am scared these instructions need a refresh and I will waste $$
what would be lovely is a 2 line like is in the instruction pasted below with 
something that will work for sure.the two directories I created are both on 
wrong branches and  dont complete a buil d
Be nice not keep downloading the 2G kernel source I know there is  a rebuild.sh 
but I am assuming that is used after a successful buildIf these instruction 
need I tweek I can understand I can test them. If it old and not supported a 
heads up would be appreciated. So I need something like this below with 
everything needed to build a kernel including the previous two steps as my two 
directories are on the wrong branches
Thanks

For TI v5.4.x: Real-Time#~/ti-linux-kernel-dev/
git checkout origin/ti-linux-rt-5.4.y -b tmp


Build:




Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s


Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.s

Build:
#user@localhost:~/ti-linux-kernel-dev$
./build_kernel.sh



On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson 
 wrote:  
 
 On Fri, May 28, 2021 at 2:53 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 2:45 PM Robert Nelson  wrote:
> >
> > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz  wrote:
> > >
> > > Thanks!!
> > >
> > > Think of it as I'm validating the instructions I think having these is 
> > > something good. Unfortunately my VM blew up just now.
> > >
> > > I KNOW your adamant about not supporting VM.
> > >
> > > So I'll build a dedicated Debian 8 dev box.
> > >
> > > Any hints tips lessons learned what you use be appreciated.
> > >
> > > Have a great long weekend.
> >
> > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
> > failure point..
>
> I think mainline might work:
>
> debian@beaglebone:~$ uname -r
> 5.13.0-rc3-bone2.2
> debian@beaglebone:~$ dmesg | grep pru
> [    2.044506] remoteproc remoteproc1: 4a334000.pru is available
> [    2.045701] remoteproc remoteproc2: 4a338000.pru is available
> debian@beaglebone:~$ ls /dev/remoteproc/pruss-core*
> /dev/remoteproc/pruss-core0:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> /dev/remoteproc/pruss-core1:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> @Mark Yoder can you test? ;)

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state
[  243.355728] remoteproc remoteproc1: powering up 4a334000.pru
[  243.366533] remoteproc remoteproc1: Booting fw image
am335x-pru0-fw, size 32456
[  243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state
[  296.981371] remoteproc remoteproc1: stopped remote processor 4a334000.pru

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/1419458740.838013.1622321132117%40mail.yahoo.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 2:53 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 2:45 PM Robert Nelson  wrote:
> >
> > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz  wrote:
> > >
> > > Thanks!!
> > >
> > > Think of it as I'm validating the instructions I think having these is 
> > > something good. Unfortunately my VM blew up just now.
> > >
> > > I KNOW your adamant about not supporting VM.
> > >
> > > So I'll build a dedicated Debian 8 dev box.
> > >
> > > Any hints tips lessons learned what you use be appreciated.
> > >
> > > Have a great long weekend.
> >
> > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
> > failure point..
>
> I think mainline might work:
>
> debian@beaglebone:~$ uname -r
> 5.13.0-rc3-bone2.2
> debian@beaglebone:~$ dmesg | grep pru
> [2.044506] remoteproc remoteproc1: 4a334000.pru is available
> [2.045701] remoteproc remoteproc2: 4a338000.pru is available
> debian@beaglebone:~$ ls /dev/remoteproc/pruss-core*
> /dev/remoteproc/pruss-core0:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> /dev/remoteproc/pruss-core1:
> coredump  device  firmware  name  power  recovery  state  subsystem  uevent
>
> @Mark Yoder can you test? ;)

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state
[  243.355728] remoteproc remoteproc1: powering up 4a334000.pru
[  243.366533] remoteproc remoteproc1: Booting fw image
am335x-pru0-fw, size 32456
[  243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up

debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state
[  296.981371] remoteproc remoteproc1: stopped remote processor 4a334000.pru

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/CAOCHtYghrd4aZdh5F85_tGZkEWj4u3MYUst6AKNgzwro8HsEoQ%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 2:45 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz  wrote:
> >
> > Thanks!!
> >
> > Think of it as I'm validating the instructions I think having these is 
> > something good. Unfortunately my VM blew up just now.
> >
> > I KNOW your adamant about not supporting VM.
> >
> > So I'll build a dedicated Debian 8 dev box.
> >
> > Any hints tips lessons learned what you use be appreciated.
> >
> > Have a great long weekend.
>
> VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
> failure point..

I think mainline might work:

debian@beaglebone:~$ uname -r
5.13.0-rc3-bone2.2
debian@beaglebone:~$ dmesg | grep pru
[2.044506] remoteproc remoteproc1: 4a334000.pru is available
[2.045701] remoteproc remoteproc2: 4a338000.pru is available
debian@beaglebone:~$ ls /dev/remoteproc/pruss-core*
/dev/remoteproc/pruss-core0:
coredump  device  firmware  name  power  recovery  state  subsystem  uevent

/dev/remoteproc/pruss-core1:
coredump  device  firmware  name  power  recovery  state  subsystem  uevent

@Mark Yoder can you test? ;)

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/CAOCHtYjjHPf9zqKcLYO7_dr4NvaenAnqwyrWaYv8HQwBFWceZw%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz  wrote:
>
> Thanks!!
>
> Think of it as I'm validating the instructions I think having these is 
> something good. Unfortunately my VM blew up just now.
>
> I KNOW your adamant about not supporting VM.
>
> So I'll build a dedicated Debian 8 dev box.
>
> Any hints tips lessons learned what you use be appreciated.
>
> Have a great long weekend.

VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the
failure point..

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/CAOCHtYhvPyONo325wtHifsdxO4cFARkFGGuu3K0xdFuBK%3DKNcQ%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

['Mark Lazarewicz' via BeagleBoard]

Thanks!! 
Think of it as I'm validating the instructions I think having these is 
something good. Unfortunately my VM blew up just now.
I KNOW your adamant about not supporting VM.
So I'll build a dedicated Debian 8 dev box.
Any hints tips lessons learned what you use be appreciated.
Have a great long weekend.
Regards

Sent from Yahoo Mail on Android 
 
  On Fri, May 28, 2021 at 2:35 PM, Robert Nelson 
wrote:   

On Fri, May 28, 2021 at 2:19 PM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

 Thanks Robert 

I love these instructions very well done 
my goal is to be able to build something stable from scratch not drop binaries 
maybe modify kernel add drivers be self sufficient at building everything and 
manually updating SD card as opposed to using an upgrade/update on the BB black.



Glad you like it, it's' my old eewiki page just updated and updated as users 
need help. ;)



Not worried about having the most current linux wont ask any questions or need 
support just trying to learn building everything myself for scratch. I have NO 
capes no changes to .dts Im interested in the workings of this resource file 
and maybe getting the big shared RAM
Thanks wish I had found this link before did not know it existed
So I guess my question is which version will work as is for testing some PRU 
MSG examples as is?

"as-is"... Either the 4.14.x-ti or 4.19.x-ti with Mark's pru cookbook:
https://markayoder.github.io/PRUCookbook/

v5.13.x: closer... just another bug:
ebian@beaglebone:~$ uname -r
5.13.0-rc3-bone2.1
debian@beaglebone:~$ dmesg | grep pru
[    2.040720] pruss 4a30.pruss: (null) is missing its 'cfg' node

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/CAOCHtYgW8-jB9B6byJEeB_KFCX6O-s2ObWc-aAzT%2B-hm3PH3Tg%40mail.gmail.com.
  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/245629638.704247.1622230855720%40mail.yahoo.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 2:19 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Thanks Robert
>
> I love these instructions very well done
> my goal is to be able to build something stable from scratch not drop
> binaries maybe modify kernel add drivers be self sufficient at building
> everything and manually updating SD card as opposed to using an
> upgrade/update on the BB black.
>


Glad you like it, it's' my old eewiki page just updated and updated as
users need help. ;)


>
> Not worried about having the most current linux wont ask any questions or
> need support just trying to learn building everything myself for scratch. I
> have NO capes no changes to .dts Im interested in the workings of this
> resource file and maybe getting the big shared RAM
> Thanks wish I had found this link before did not know it existed
>
> So I guess my question is which version will work as is for testing some
> PRU MSG examples as is?
>

"as-is"... Either the 4.14.x-ti or 4.19.x-ti with Mark's pru cookbook:

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

v5.13.x: closer... just another bug:

ebian@beaglebone:~$ uname -r
5.13.0-rc3-bone2.1
debian@beaglebone:~$ dmesg | grep pru
[2.040720] pruss 4a30.pruss: (null) is missing its 'cfg' node

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/CAOCHtYgW8-jB9B6byJEeB_KFCX6O-s2ObWc-aAzT%2B-hm3PH3Tg%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

['Mark Lazarewicz' via BeagleBoard]

 Thanks Robert 

I love these instructions very well done 
my goal is to be able to build something stable from scratch not drop binaries 
maybe modify kernel add drivers be self sufficient at building everything and 
manually updating SD card as opposed to using an upgrade/update on the BB black.


Not worried about having the most current linux wont ask any questions or need 
support just trying to learn building everything myself for scratch. I have NO 
capes no changes to .dts Im interested in the workings of this resource file 
and maybe getting the big shared RAM
Thanks wish I had found this link before did not know it existed
So I guess my question is which version will work as is for testing some PRU 
MSG examples as is?

Mark

On Friday, May 28, 2021, 1:45:35 PM CDT, Robert Nelson 
 wrote:  
 
 

On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

 Dumb question by a Debian Newb 

I am following this now Debian: Getting Started with the BeagleBone Black

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Debian: Getting Started with the BeagleBone Black

This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability 
Boards: BeagleBone Black at Digi-K...
 |

 |

 |


To test this PRU stuff should I use Mainline or TI BSP? whats the difference?

As we speak Im cloning the TI BSP version and looks like somehow I am on 4.14 
Branch . I had bad internet last night and I lost the building during resolve 
after downloading the entire kernel of mainline . Today Im trying TI BSP 

cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into 
default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src




Use the "am33x-v5.13" branch of: https://github.com/RobertCNelson/bb-kernel
There are "pre-builds" under apt...
But, I think we need to update the device tree..
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/CAOCHtYjoJEDJgvnwdcz%2B-3ktqFCTmyebB3qF41g2mMSGij1hiA%40mail.gmail.com.
  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/281626775.704459.169545384%40mail.yahoo.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 1:54 PM Robert Nelson 
wrote:

>
>
> On Fri, May 28, 2021 at 1:45 PM Robert Nelson 
> wrote:
>
>>
>>
>> On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard <
>> beagleboard@googlegroups.com> wrote:
>>
>>> Dumb question by a Debian Newb
>>>
>>> I am following this now Debian: Getting Started with the BeagleBone
>>> Black
>>> 
>>>
>>> Debian: Getting Started with the BeagleBone Black
>>>
>>> This is a page about TI's Cortex-A8 based; BeagleBone Black.
>>> Availability Boards: BeagleBone Black at Digi-K...
>>>
>>> 
>>>
>>> To test this PRU stuff should I use Mainline or TI BSP? whats the
>>> difference?
>>>
>>> As we speak Im cloning the TI BSP version and looks like somehow I am on
>>> 4.14 Branch . I had bad internet last night and I lost the building during
>>> resolve after downloading the entire kernel of mainline . Today Im trying
>>> TI BSP
>>>
>>> cloning
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into
>>> default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src
>>>
>>>
>>>
>> Use the "am33x-v5.13" branch of:
>> https://github.com/RobertCNelson/bb-kernel
>>
>> There are "pre-builds" under apt...
>>
>> But, I think we need to update the device tree..
>>
>
> Thinking:
>
>
> https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/7a960d2e3e04a5418772cddd51493ad8578eccf6
>
>
And the interrupt controller..

https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/68aea0792284d7b3c58741c62738287762a5cc0c

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/CAOCHtYhN1So9WaXarGMtb6sqP3OES_ZHmvk26WYsG-R5OoZk0g%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 1:45 PM Robert Nelson 
wrote:

>
>
> On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
>> Dumb question by a Debian Newb
>>
>> I am following this now Debian: Getting Started with the BeagleBone Black
>> 
>>
>> Debian: Getting Started with the BeagleBone Black
>>
>> This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability
>> Boards: BeagleBone Black at Digi-K...
>>
>> 
>>
>> To test this PRU stuff should I use Mainline or TI BSP? whats the
>> difference?
>>
>> As we speak Im cloning the TI BSP version and looks like somehow I am on
>> 4.14 Branch . I had bad internet last night and I lost the building during
>> resolve after downloading the entire kernel of mainline . Today Im trying
>> TI BSP
>>
>> cloning
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into
>> default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src
>>
>>
>>
> Use the "am33x-v5.13" branch of:
> https://github.com/RobertCNelson/bb-kernel
>
> There are "pre-builds" under apt...
>
> But, I think we need to update the device tree..
>

Thinking:

https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/7a960d2e3e04a5418772cddd51493ad8578eccf6

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/CAOCHtYgDgNBuGh05MRkN8BLmJ%3DUvc9wZgY6vOVCdMiS4rHfeYA%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Dumb question by a Debian Newb
>
> I am following this now Debian: Getting Started with the BeagleBone Black
> 
>
> Debian: Getting Started with the BeagleBone Black
>
> This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability
> Boards: BeagleBone Black at Digi-K...
>
> 
>
> To test this PRU stuff should I use Mainline or TI BSP? whats the
> difference?
>
> As we speak Im cloning the TI BSP version and looks like somehow I am on
> 4.14 Branch . I had bad internet last night and I lost the building during
> resolve after downloading the entire kernel of mainline . Today Im trying
> TI BSP
>
> cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> into default location:
> /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src
>
>
>
Use the "am33x-v5.13" branch of: https://github.com/RobertCNelson/bb-kernel

There are "pre-builds" under apt...

But, I think we need to update the device tree..

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/CAOCHtYjoJEDJgvnwdcz%2B-3ktqFCTmyebB3qF41g2mMSGij1hiA%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

['Mark Lazarewicz' via BeagleBoard]

 Dumb question by a Debian Newb 

I am following this now Debian: Getting Started with the BeagleBone Black

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Debian: Getting Started with the BeagleBone Black

This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability 
Boards: BeagleBone Black at Digi-K...
 |

 |

 |


To test this PRU stuff should I use Mainline or TI BSP? whats the difference?

As we speak Im cloning the TI BSP version and looks like somehow I am on 4.14 
Branch . I had bad internet last night and I lost the building during resolve 
after downloading the entire kernel of mainline . Today Im trying TI BSP 

cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into 
default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src



On Friday, May 28, 2021, 12:57:48 PM CDT, Robert Nelson 
 wrote:  
 
 On Fri, May 28, 2021 at 12:53 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 12:51 PM Robert Nelson  
> wrote:
> >
> > On Fri, May 28, 2021 at 12:47 PM Bruce Chidester
> >  wrote:
> > >
> > > Does the 5.x kernel support an interrupt from the PRU while also 
> > > supporting the bi-directional messaging through rproc?
> >
> > sorry, i completely missed these commits, so i have not personally
> > tested it... It got merged in v5.11.x and has been tweaked since..
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml?h=v5.13-rc3
> >
> > it "should" be an extension of the pru code found in
> > v4.14.x-ti/v4.19.x-ti/v5.4.x-ti..
>
> I see lots of interrupt hints here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c

irq driver for pru:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-pruss-intc.c

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/CAOCHtYjHr%3D2Mx%2BKLa9enn2pd9rfid0SQ6kVw7ZNh8RPgJpZiFA%40mail.gmail.com.
  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/546397207.693159.167127508%40mail.yahoo.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 12:53 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 12:51 PM Robert Nelson  
> wrote:
> >
> > On Fri, May 28, 2021 at 12:47 PM Bruce Chidester
> >  wrote:
> > >
> > > Does the 5.x kernel support an interrupt from the PRU while also 
> > > supporting the bi-directional messaging through rproc?
> >
> > sorry, i completely missed these commits, so i have not personally
> > tested it... It got merged in v5.11.x and has been tweaked since..
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml?h=v5.13-rc3
> >
> > it "should" be an extension of the pru code found in
> > v4.14.x-ti/v4.19.x-ti/v5.4.x-ti..
>
> I see lots of interrupt hints here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c

irq driver for pru:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-pruss-intc.c

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/CAOCHtYjHr%3D2Mx%2BKLa9enn2pd9rfid0SQ6kVw7ZNh8RPgJpZiFA%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 12:51 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 12:47 PM Bruce Chidester
>  wrote:
> >
> > Does the 5.x kernel support an interrupt from the PRU while also supporting 
> > the bi-directional messaging through rproc?
>
> sorry, i completely missed these commits, so i have not personally
> tested it... It got merged in v5.11.x and has been tweaked since..
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml?h=v5.13-rc3
>
> it "should" be an extension of the pru code found in
> v4.14.x-ti/v4.19.x-ti/v5.4.x-ti..

I see lots of interrupt hints here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c

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/CAOCHtYhhPL8UMw14fV9rvJviCFvpbviWNuxaU8pxepVX42G4CQ%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 12:47 PM Bruce Chidester
 wrote:
>
> Does the 5.x kernel support an interrupt from the PRU while also supporting 
> the bi-directional messaging through rproc?

sorry, i completely missed these commits, so i have not personally
tested it... It got merged in v5.11.x and has been tweaked since..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml?h=v5.13-rc3

it "should" be an extension of the pru code found in
v4.14.x-ti/v4.19.x-ti/v5.4.x-ti..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYj40mHeMBVKHq%2B9jZ00c%2BqOBqs%3DFA%2BNSYOK4cFwsQ4hiQ%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Bruce Chidester]

Does the 5.x kernel support an interrupt from the PRU while also supporting 
the bi-directional messaging through rproc?

On Friday, May 28, 2021 at 12:38:08 PM UTC-5 RobertCNelson wrote:

> On Fri, May 28, 2021 at 12:36 PM Robert Nelson  
> wrote:
> >
> > On Fri, May 28, 2021 at 12:21 PM Bruce Chidester
> >  wrote:
> > >
> > > I'm confused because I thought the plan was Remote Proc going forward. 
> Do you seem to say it is UIO going forward?
> >
> > Mainline has been 'slowly' getting RemoteProc work done by TI..
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/remoteproc/pru_rproc.c
>
> 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/f1665040-057c-49a4-b5b9-50b853efecfcn%40googlegroups.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 12:36 PM Robert Nelson  wrote:
>
> On Fri, May 28, 2021 at 12:21 PM Bruce Chidester
>  wrote:
> >
> > I'm confused because I thought the plan was Remote Proc going forward. Do 
> > you seem to say it is UIO going forward?
>
> Mainline has been 'slowly' getting RemoteProc work done by TI..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/remoteproc/pru_rproc.c

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/CAOCHtYjY_bTHv4TyhMbuu-J9m8V8gbo810t%2BWh9d2d-S62LLow%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Heller]

At Fri, 28 May 2021 10:21:11 -0700 (PDT) beagleboard@googlegroups.com wrote:

> 
> I'm confused because I thought the plan was Remote Proc going forward. Do 
> you seem to say it is UIO going forward?

Only that the *stock* mainline kernels don't have Remote Proc support.  I 
guess TI has not gotten around to porting things yet or the kernel builder 
devs have not built the 5.x kernels with Remote Proc:

from /boot/config-4.19.94-ti-r42:
#
# Rpmsg drivers
#
CONFIG_RPMSG=y
# CONFIG_RPMSG_CHAR is not set
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
CONFIG_RPMSG_VIRTIO=m
CONFIG_RPMSG_RPC=m
CONFIG_RPMSG_PRU=m

#
# Rpmsg virtual device drivers
#
CONFIG_RPMSG_KDRV=y
CONFIG_RPMSG_KDRV_DISPLAY=y
CONFIG_RPMSG_KDRV_ETH_SWITCH=m


from /boot/config-5.4.102-bone45:
#
# Rpmsg drivers
#
CONFIG_RPMSG=m
CONFIG_RPMSG_CHAR=m
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
CONFIG_RPMSG_VIRTIO=m
# end of Rpmsg drivers


> 
> On Friday, May 28, 2021 at 12:15:34 PM UTC-5 hel...@deepsoft.com wrote:
> 
> > At Fri, 28 May 2021 12:59:20 -0400 beagl...@googlegroups.com wrote:
> >
> > > 
> > > On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
> > > gmane.comp.hardware.beagleboard.user Bruce Chidester
> > >  wrote:
> > > 
> > > >I am using BBB Revision C
> > > >
> > > >Please help me get clarity on my assumptions that I believe I have 
> > learned 
> > > >so far and tell me where I am incorrect:
> > > 
> > > Can't confirm for everything, but...
> > > >
> > > >1. There are 2 architectures to interact with the PRU's. They are *UIO* 
> > and 
> > > >*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt 
> > file. 
> > > >You cannot run both at the same time.
> > > 
> > > TRUE -- but maybe not "easily"; there are some dependencies upon the
> > > kernel version loaded.
> >
> > YES. 5.x kernels only support UIO. You need a 4.x TI kernel for RemoteProc.
> >
> > > 
> > > TI has deprecated UIO and considers RemoteProc to be the route for
> > > future usage (it is not tied to just the PRUs, it should work with the 
> > DSP
> > > chips on the BB AI, et al.).
> >
> > I think the mainline kernels don't have the RemoteProc kernel code. At 
> > least 
> > by default.
> >
> > > 
> > > >
> > > >2. When using RemoteProc you can *send* a remote message to the PRU and 
> > > >this solution *does not work* with UIO.
> > > 
> > > RPMsg supports sending message in both directions
> > > 
> > https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
> > > """
> > > There are two vrings provided per PRU core, one vring is used for 
> > messages
> > > passed to the ARM and the other vring is used for messages received from
> > > the ARM. System level mailboxes are used to notify cores (ARM or PRU) 
> > when
> > > new messages are waiting in the shared buffers.
> > > """
> > > 
> > > >
> > > >3. When using UIO the PRU can *send* an Interrupt to the host code but 
> > > >RemoteProc *cannot*.
> > > >
> > > >4. When using UIO, you *cannot* send an interrupt to the PRU, you need 
> > to 
> > > >create some other solution maybe through shared memory.
> > > >
> > > 
> > > As the PRUs do not have what I would call true interrupts (they have a
> > > set of "interrupt bits" but do NOT interrupt the processor, the bits have
> > > to be polled, and appropriate handlers called) any talk of interrupts is
> > > vague.
> > > 
> > > However, for RPMsg, the "mailbox" provides, I believe, some form of
> > > blocked wait or maybe use of a select() call to test for mailbox data. I
> > > don't really know what a "Kick" entails in:
> > > """
> > > ARM Host Steps
> > > Step 1a: Allocate a new buffer -or-
> > > Step 1b: Get a Used buffer from the slave Vring
> > > Step 2: Copy data to be transferred into the buffer from Step 1
> > > Step 3: Add the newly filled buffer to the Available list in the
> > > slave Vring
> > > Step 4: Kick the slave Vring by writing its index (1) into a
> > > message in Mailbox 2
> > > PRU Steps
> > > Step 5: A Kick is discovered in Mailbox 2 with the index of the
> > > Kicked Vring (1). This indicates to the PRU that data is available for
> > > receive
> > > Step 6: Get the Available buffer from the slave Vring
> > > Step 7: Copy data to be received out of the buffer from Step 2
> > > Step 8: Add the now empty buffer to the Used list in the slave
> > > Vring
> > > Step 9: Kick the slave Vring by writing its index (1) into a
> > > message in Mailbox 3
> > > """
> > > Step five appears to be a polling loop on the mailbox.
> > > 
> > > 
> > > 
> > > 
> >
> > -- 
> > Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
> > <(978)%20633-5364>
> > Deepwoods Software -- Custom Software Services
> > http://www.deepsoft.com/ -- Linux Administration Services
> > hel...@deepsoft.com -- Webhosting Services
> >
> >
> 

-- 
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration 

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Nelson]

On Fri, May 28, 2021 at 12:21 PM Bruce Chidester
 wrote:
>
> I'm confused because I thought the plan was Remote Proc going forward. Do you 
> seem to say it is UIO going forward?

Mainline has been 'slowly' getting RemoteProc work done by TI..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYh_GaR%2BHQgGSogRKoHegfdjvRpxe_jn7N3UARmiTwcxgQ%40mail.gmail.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Bruce Chidester]

I'm confused because I thought the plan was Remote Proc going forward. Do 
you seem to say it is UIO going forward?

On Friday, May 28, 2021 at 12:15:34 PM UTC-5 hel...@deepsoft.com wrote:

> At Fri, 28 May 2021 12:59:20 -0400 beagl...@googlegroups.com wrote:
>
> > 
> > On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
> > gmane.comp.hardware.beagleboard.user Bruce Chidester
> >  wrote:
> > 
> > >I am using BBB Revision C
> > >
> > >Please help me get clarity on my assumptions that I believe I have 
> learned 
> > >so far and tell me where I am incorrect:
> > 
> > Can't confirm for everything, but...
> > >
> > >1. There are 2 architectures to interact with the PRU's. They are *UIO* 
> and 
> > >*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt 
> file. 
> > >You cannot run both at the same time.
> > 
> > TRUE -- but maybe not "easily"; there are some dependencies upon the
> > kernel version loaded.
>
> YES. 5.x kernels only support UIO. You need a 4.x TI kernel for RemoteProc.
>
> > 
> > TI has deprecated UIO and considers RemoteProc to be the route for
> > future usage (it is not tied to just the PRUs, it should work with the 
> DSP
> > chips on the BB AI, et al.).
>
> I think the mainline kernels don't have the RemoteProc kernel code. At 
> least 
> by default.
>
> > 
> > >
> > >2. When using RemoteProc you can *send* a remote message to the PRU and 
> > >this solution *does not work* with UIO.
> > 
> > RPMsg supports sending message in both directions
> > 
> https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
> > """
> > There are two vrings provided per PRU core, one vring is used for 
> messages
> > passed to the ARM and the other vring is used for messages received from
> > the ARM. System level mailboxes are used to notify cores (ARM or PRU) 
> when
> > new messages are waiting in the shared buffers.
> > """
> > 
> > >
> > >3. When using UIO the PRU can *send* an Interrupt to the host code but 
> > >RemoteProc *cannot*.
> > >
> > >4. When using UIO, you *cannot* send an interrupt to the PRU, you need 
> to 
> > >create some other solution maybe through shared memory.
> > >
> > 
> > As the PRUs do not have what I would call true interrupts (they have a
> > set of "interrupt bits" but do NOT interrupt the processor, the bits have
> > to be polled, and appropriate handlers called) any talk of interrupts is
> > vague.
> > 
> > However, for RPMsg, the "mailbox" provides, I believe, some form of
> > blocked wait or maybe use of a select() call to test for mailbox data. I
> > don't really know what a "Kick" entails in:
> > """
> > ARM Host Steps
> > Step 1a: Allocate a new buffer -or-
> > Step 1b: Get a Used buffer from the slave Vring
> > Step 2: Copy data to be transferred into the buffer from Step 1
> > Step 3: Add the newly filled buffer to the Available list in the
> > slave Vring
> > Step 4: Kick the slave Vring by writing its index (1) into a
> > message in Mailbox 2
> > PRU Steps
> > Step 5: A Kick is discovered in Mailbox 2 with the index of the
> > Kicked Vring (1). This indicates to the PRU that data is available for
> > receive
> > Step 6: Get the Available buffer from the slave Vring
> > Step 7: Copy data to be received out of the buffer from Step 2
> > Step 8: Add the now empty buffer to the Used list in the slave
> > Vring
> > Step 9: Kick the slave Vring by writing its index (1) into a
> > message in Mailbox 3
> > """
> > Step five appears to be a polling loop on the mailbox.
> > 
> > 
> > 
> > 
>
> -- 
> Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
> <(978)%20633-5364>
> Deepwoods Software -- Custom Software Services
> http://www.deepsoft.com/ -- Linux Administration Services
> hel...@deepsoft.com -- Webhosting Services
>
>

-- 
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/32060533-8294-43ec-a812-969ddc9b83c5n%40googlegroups.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Robert Heller]

At Fri, 28 May 2021 12:59:20 -0400 beagleboard@googlegroups.com wrote:

> 
> On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Bruce Chidester
>  wrote:
> 
> >I am using BBB Revision C
> >
> >Please help me get clarity on my assumptions that I believe I have learned 
> >so far and tell me where I am incorrect:
> 
>   Can't confirm for everything, but...
> >
> >1. There are 2 architectures to interact with the PRU's. They are *UIO* and 
> >*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt file. 
> >You cannot run both at the same time.
> 
>   TRUE -- but maybe not "easily"; there are some dependencies upon the
> kernel version loaded.

YES.  5.x kernels only support UIO.  You need a 4.x TI kernel for RemoteProc.

> 
>   TI has deprecated UIO and considers RemoteProc to be the route for
> future usage (it is not tied to just the PRUs, it should work with the DSP
> chips on the BB AI, et al.).

I think the mainline kernels don't have the RemoteProc kernel code.  At least 
by default.

> 
> >
> >2. When using RemoteProc you can *send* a remote message to the PRU and 
> >this solution *does not work* with UIO.
> 
>   RPMsg supports sending message in both directions
> https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
> """
> There are two vrings provided per PRU core, one vring is used for messages
> passed to the ARM and the other vring is used for messages received from
> the ARM. System level mailboxes are used to notify cores (ARM or PRU) when
> new messages are waiting in the shared buffers.
> """
> 
> >
> >3. When using UIO the PRU can *send* an Interrupt to the host code but 
> >RemoteProc *cannot*.
> >
> >4. When using UIO, you *cannot* send an interrupt to the PRU, you need to 
> >create some other solution maybe through shared memory.
> >
> 
>   As the PRUs do not have what I would call true interrupts (they have a
> set of "interrupt bits" but do NOT interrupt the processor, the bits have
> to be polled, and appropriate handlers called) any talk of interrupts is
> vague.
> 
>   However, for RPMsg, the "mailbox" provides, I believe, some form of
> blocked wait or maybe use of a select() call to test for mailbox data. I
> don't really know what a "Kick" entails in:
> """
> ARM Host Steps
> Step 1a: Allocate a new buffer -or-
> Step 1b: Get a Used buffer from the slave Vring
> Step 2: Copy data to be transferred into the buffer from Step 1
> Step 3: Add the newly filled buffer to the Available list in the
> slave Vring
> Step 4: Kick the slave Vring by writing its index (1) into a
> message in Mailbox 2
> PRU Steps
> Step 5: A Kick is discovered in Mailbox 2 with the index of the
> Kicked Vring (1). This indicates to the PRU that data is available for
> receive
> Step 6: Get the Available buffer from the slave Vring
> Step 7: Copy data to be received out of the buffer from Step 2
> Step 8: Add the now empty buffer to the Used list in the slave
> Vring
> Step 9: Kick the slave Vring by writing its index (1) into a
> message in Mailbox 3
> """
>   Step five appears to be a polling loop on the mailbox.
> 
> 
> 
> 

-- 
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services

  

-- 
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/20210528171520.B4112223267%40sharky4.deepsoft.com.