Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-19 Thread 'Mark Lazarewicz' via BeagleBoard 
Darren
People with 10k products in market use DSP for very fast matlab generated motor 
control the code is designed by PhDs in Control Theory. Same product uses PRU 
for LCD and extra UART. Product used every peripheral on ARM and DSP side used 
RTOS on DPS and communicated to TI c2000  DPS via SPI that did encoder. Notice 
the PRU controlled non hard realtime functions as the DSP ran bios with a clock 
tick in the nanoseconds. The only reason the PRU is deterministic is because 
it's bare bones. This product the ARM is only a host running a fail safe 
industrial redundant networking protocol. It loads the DSP and starts the 
network stack. It also loads the C2000 and dumps debug info into a custom 
messaging queue high priority and low priority. The PRU  UART ran a  monitor to 
dump debug info from queues to debug. The controls theory generated filters ran 
on DSP. I do remember the PhDs and geniuses who designed this in two years got 
an algorithm from TI application engineer's it set up the caches in in the 
shared memory the DPS code ran on to make it blazing fast. You get that kind of 
support when you buy 10k chips and deliver  real products consistently. The ARM 
ran Greenhill Integrity came with a BSP to initialize MUM and a custom second 
phase loader written by board support geniuses at GreenHills. You kind of 
support when buy a proven RTOS. Check the block diagrams to confirm the shared 
memory exists between PRU and DSP it may not exist if not make sure PRU can 
access DDR.
The advantage of using the SDK is it covers all the pieces. C6xx GCC support 
makes it less turnkey. ASK is turnkey it's what they give you with EVM to get 
products to market  fast. IMO you mix Apple's and oranges and they go rotten in 
the barrel which farmer do you ask for help? The Apple farmer points at the 
orange farmer 藍

Sent from Yahoo Mail on Android 
 
  On Fri, Feb 19, 2021 at 12:47 PM, Darren Freed wrote:  
 I'm using Debian, and relied heavily on Mark Yoder's PRU cookbook to get one 
of the PRUs receiving analog data from an ADS1299 via SPI (bitbang on the PRU), 
and the data is then sent over to the A15 side via rpmsg.  Although I can't 
really complain about how things are working, I feel like I should be able to 
get greater efficiency from the setup if I could use one of the DSPs to do 
signal processing, and take that load off the A15. So I'm thinking 
PRU->DSP->A15 for the data flow.
Your point about the SDK is well taken.  I will work through those resources!
Many thanks,df



On Thu, Feb 18, 2021 at 9:43 PM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

Hi Darren
Jeff has actual hardware I dont hopefully  we will summarize soon.
What is your application. Define it. Are you just playing or does it have 
requirements?Do you use RPMSG now?Do you have jtag?Are you open to an IDE like 
CCS to compile C66 code or want  command line Will your DSP share data with ARM 
is it barebones or RTOS?

And the biggest unresolved what happens if your Linux app can't use Debian we 
hope that's not the case but can you learn how to build stuff and have the time 
to learn in a Yocto environment and meet your project deadlines teach yourself 
TI RTOS and maybe break your PRU application 
How much time do you have?
At a minimum you will need to read all SDK documents,  decide about  RTOS or 
barebones it's kind of like a cookbook but Building DSP code isn't documented 
anywhere else if it is no can find it.
Basically you should start reading Linux  SDK/RTOS  docs for AI right  now 
install tools and modify  your board for JTAG debugging if you really want to 
learn real world skills with source level debugging. If your goal is copying a 
DSP binary to ARM to see DSP to ARM IPC this works right now guaranteed if you 
run SDK linux Jeff is verifying will it work on Debian it should we don't know.
Either way the answer is well documented had you looked and downloaded the SDK 
it explains how to utilize an AM5729 DSP. And with JTAG it doesn't matter what 
Linux is running on ARM and it really  shouldn't anyway. Jeff's verifying that 
true.
I suggest you got lots of reading to do and tools to install easy week of fun.
What are waiting for 藍
You got 2 engineer's with 60 year's experience to ask questions for a 1 week go 
for it



Sent from Yahoo Mail on Android 
 
  On Thu, Feb 18, 2021 at 8:34 PM, Darren Freed wrote:   
Gentlemen,
I have been lurking here as a total noob, trying to exploit all the goodness in 
the AI.  For my application (University level physiology project), I've got the 
AI running well, using one of the PRUs for deterministic I/O (Thanks to Mark 
Yoder's PRU Cookbook), but I would love to be able to get the DSPs going as 
well.  So please keep up the good work and let us know what you're able to 
uncover and get working.
df

On Thu, Feb 18, 2021 at 6:55 PM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

 Jeff
I have found much more documentation including how to move and change the DSP 
and M4 carve outs sizes 

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-19 Thread jeff....@gmail.com 
I'm still learning Linux and how the multi-processor scheme works, but I'll 
share what I find out.

I forgot about that... probably worthwhile to read Professor Yoder's PRU 
Cookbook as it would some light on pmsg/rproc and the IPC considerations 
for the C66x from the BeagleBone/BeagleBoard perspective.. 

On Thursday, February 18, 2021 at 11:43:18 PM UTC-5 lazarman wrote:

> Hi Darren
>
> Jeff has actual hardware I dont
>  hopefully  we will summarize soon.
>
> What is your application. Define it. Are you just playing or does it have 
> requirements?
> Do you use RPMSG now?
> Do you have jtag?
> Are you open to an IDE like CCS to compile C66 code or want  command line 
> Will your DSP share data with ARM is it barebones or RTOS?
>
>
> And the biggest unresolved what happens if your Linux app can't use Debian 
> we hope that's not the case but can you learn how to build stuff and have 
> the time to learn in a Yocto environment and meet your project deadlines 
> teach yourself TI RTOS and maybe break your PRU application 
>
> How much time do you have?
>
> At a minimum you will need to read all SDK documents,  decide about  RTOS 
> or barebones it's kind of like a cookbook but Building DSP code isn't 
> documented anywhere else if it is no can find it.
>
> Basically you should start reading Linux  SDK/RTOS  docs for AI right  now 
> install tools and modify  your board for JTAG debugging if you really want 
> to learn real world skills with source level debugging. If your goal is 
> copying a DSP binary to ARM to see DSP to ARM IPC this works right now 
> guaranteed if you run SDK linux Jeff is verifying will it work on Debian it 
> should we don't know.
>
> Either way the answer is well documented had you looked and downloaded the 
> SDK it explains how to utilize an AM5729 DSP. And with JTAG it doesn't 
> matter what Linux is running on ARM and it really  shouldn't anyway. Jeff's 
> verifying that true.
>
> I suggest you got lots of reading to do and tools to install easy week of 
> fun.
>
> What are waiting for 藍
>
> You got 2 engineer's with 60 year's experience to ask questions for a 1 
> week go for it
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Thu, Feb 18, 2021 at 8:34 PM, Darren Freed
>  wrote:
>
> Gentlemen,
>
> I have been lurking here as a total noob, trying to exploit all the 
> goodness in the AI.  For my application (University level physiology 
> project), I've got the AI running well, using one of the PRUs for 
> deterministic I/O (Thanks to Mark Yoder's PRU Cookbook), but I would love 
> to be able to get the DSPs going as well.  So please keep up the good work 
> and let us know what you're able to uncover and get working.
>
> df
>
>
> On Thu, Feb 18, 2021 at 6:55 PM 'Mark Lazarewicz' via BeagleBoard <
> beagl...@googlegroups.com> wrote:
>
> Jeff
>
> I have found much more documentation including how to move and change the 
> DSP and M4 carve outs sizes  some of it references the TRM but summarizes 
> it for a newb like myself and the three people in this group including you 
> that needed it and asked 
> There a professor at UIC who needs this data as well his use case is TI 
> RTOS DSP apps /Debian for his class
>
> Part of the problem is the SDK documents which describe RPMsg and Remote 
> Proc were shuffled around for some reason
>
> I saw a panic post in this group about preserving some wiki data I hope 
> its not this data I am grabbing everything I can related including TRM
>
> Bottom line you can do anything you want in SDK with any core and the Docs 
> are Gonzo good 
>
>  I'm not seeing the OP even responding and dont know why they didnt dig 
> deeper maybe they waiting for you to code it all up LOL
>
> I see no value in confusing anyone more in here except a summary after 
> this post to help the students and Professor
>
> You are confusing me abit about what you have working  probally because I 
> have not digested all the docs I found and digested your comments and 
> replys which are very generous
>
> Give me a day to digest the SDK provided docs and email me directly if you 
> have questions I feel confident enough to buy a board probally AI and play 
> with SDK Linux and TI RTOS examples with and without JTAG and CCS  we have 
> different goals I dont need Debian but you and me are good if you need me 
> or think I can help your doing quite well.
>
> reply directlyto lazarman and  please watch that you dont share private 
> stuff in this group like the recruiter story you posted i  this group that 
> doesnt belong in here  Im sure that was an accident but I feel I have found 
> a friend and appreciate your feedback.
>
> Lets regroup for a day and do our homework so we can summarize our 
> research I need HW so I am envious you are a step ahead but I have more 
> than enough docs to realize this is very well documented 
>
> Cheers my friend
>
> Mark
>
> On Thursday, February 18, 2021, 07:05:35 PM CST,

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-19 Thread Darren Freed 
I'm using Debian, and relied heavily on Mark Yoder's PRU cookbook to get
one of the PRUs receiving analog data from an ADS1299 via SPI (bitbang on
the PRU), and the data is then sent over to the A15 side via rpmsg.
Although I can't really complain about how things are working, I feel like
I should be able to get greater efficiency from the setup if I could use
one of the DSPs to do signal processing, and take that load off the A15. So
I'm thinking PRU->DSP->A15 for the data flow.

Your point about the SDK is well taken.  I will work through those
resources!

Many thanks,
df



On Thu, Feb 18, 2021 at 9:43 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Hi Darren
>
> Jeff has actual hardware I dont
>  hopefully  we will summarize soon.
>
> What is your application. Define it. Are you just playing or does it have
> requirements?
> Do you use RPMSG now?
> Do you have jtag?
> Are you open to an IDE like CCS to compile C66 code or want  command line
> Will your DSP share data with ARM is it barebones or RTOS?
>
>
> And the biggest unresolved what happens if your Linux app can't use Debian
> we hope that's not the case but can you learn how to build stuff and have
> the time to learn in a Yocto environment and meet your project deadlines
> teach yourself TI RTOS and maybe break your PRU application 
>
> How much time do you have?
>
> At a minimum you will need to read all SDK documents,  decide about  RTOS
> or barebones it's kind of like a cookbook but Building DSP code isn't
> documented anywhere else if it is no can find it.
>
> Basically you should start reading Linux  SDK/RTOS  docs for AI right  now
> install tools and modify  your board for JTAG debugging if you really want
> to learn real world skills with source level debugging. If your goal is
> copying a DSP binary to ARM to see DSP to ARM IPC this works right now
> guaranteed if you run SDK linux Jeff is verifying will it work on Debian it
> should we don't know.
>
> Either way the answer is well documented had you looked and downloaded the
> SDK it explains how to utilize an AM5729 DSP. And with JTAG it doesn't
> matter what Linux is running on ARM and it really  shouldn't anyway. Jeff's
> verifying that true.
>
> I suggest you got lots of reading to do and tools to install easy week of
> fun.
>
> What are waiting for 藍
>
> You got 2 engineer's with 60 year's experience to ask questions for a 1
> week go for it
>
>
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Thu, Feb 18, 2021 at 8:34 PM, Darren Freed
>  wrote:
> Gentlemen,
>
> I have been lurking here as a total noob, trying to exploit all the
> goodness in the AI.  For my application (University level physiology
> project), I've got the AI running well, using one of the PRUs for
> deterministic I/O (Thanks to Mark Yoder's PRU Cookbook), but I would love
> to be able to get the DSPs going as well.  So please keep up the good work
> and let us know what you're able to uncover and get working.
>
> df
>
>
> On Thu, Feb 18, 2021 at 6:55 PM 'Mark Lazarewicz' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
> Jeff
>
> I have found much more documentation including how to move and change the
> DSP and M4 carve outs sizes  some of it references the TRM but summarizes
> it for a newb like myself and the three people in this group including you
> that needed it and asked
> There a professor at UIC who needs this data as well his use case is TI
> RTOS DSP apps /Debian for his class
>
> Part of the problem is the SDK documents which describe RPMsg and Remote
> Proc were shuffled around for some reason
>
> I saw a panic post in this group about preserving some wiki data I hope
> its not this data I am grabbing everything I can related including TRM
>
> Bottom line you can do anything you want in SDK with any core and the Docs
> are Gonzo good
>
>  I'm not seeing the OP even responding and dont know why they didnt dig
> deeper maybe they waiting for you to code it all up LOL
>
> I see no value in confusing anyone more in here except a summary after
> this post to help the students and Professor
>
> You are confusing me abit about what you have working  probally because I
> have not digested all the docs I found and digested your comments and
> replys which are very generous
>
> Give me a day to digest the SDK provided docs and email me directly if you
> have questions I feel confident enough to buy a board probally AI and play
> with SDK Linux and TI RTOS examples with and without JTAG and CCS  we have
> different goals I dont need Debian but you and me are good if you need me
> or think I can help your doing quite well.
>
> reply directlyto lazarman and  please watch that you dont share private
> stuff in this group like the recruiter story you posted i  this group that
> doesnt belong in here  Im sure that was an accident but I feel I have found
> a friend and appreciate your feedback.
>
> Lets regroup for a day

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread 'Mark Lazarewicz' via BeagleBoard 
Hi Darren
Jeff has actual hardware I dont hopefully  we will summarize soon.
What is your application. Define it. Are you just playing or does it have 
requirements?Do you use RPMSG now?Do you have jtag?Are you open to an IDE like 
CCS to compile C66 code or want  command line Will your DSP share data with ARM 
is it barebones or RTOS?

And the biggest unresolved what happens if your Linux app can't use Debian we 
hope that's not the case but can you learn how to build stuff and have the time 
to learn in a Yocto environment and meet your project deadlines teach yourself 
TI RTOS and maybe break your PRU application 
How much time do you have?
At a minimum you will need to read all SDK documents,  decide about  RTOS or 
barebones it's kind of like a cookbook but Building DSP code isn't documented 
anywhere else if it is no can find it.
Basically you should start reading Linux  SDK/RTOS  docs for AI right  now 
install tools and modify  your board for JTAG debugging if you really want to 
learn real world skills with source level debugging. If your goal is copying a 
DSP binary to ARM to see DSP to ARM IPC this works right now guaranteed if you 
run SDK linux Jeff is verifying will it work on Debian it should we don't know.
Either way the answer is well documented had you looked and downloaded the SDK 
it explains how to utilize an AM5729 DSP. And with JTAG it doesn't matter what 
Linux is running on ARM and it really  shouldn't anyway. Jeff's verifying that 
true.
I suggest you got lots of reading to do and tools to install easy week of fun.
What are waiting for 藍
You got 2 engineer's with 60 year's experience to ask questions for a 1 week go 
for it



Sent from Yahoo Mail on Android 
 
  On Thu, Feb 18, 2021 at 8:34 PM, Darren Freed wrote:   
Gentlemen,
I have been lurking here as a total noob, trying to exploit all the goodness in 
the AI.  For my application (University level physiology project), I've got the 
AI running well, using one of the PRUs for deterministic I/O (Thanks to Mark 
Yoder's PRU Cookbook), but I would love to be able to get the DSPs going as 
well.  So please keep up the good work and let us know what you're able to 
uncover and get working.
df

On Thu, Feb 18, 2021 at 6:55 PM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

 Jeff
I have found much more documentation including how to move and change the DSP 
and M4 carve outs sizes  some of it references the TRM but summarizes it for a 
newb like myself and the three people in this group including you that needed 
it and asked There a professor at UIC who needs this data as well his use case 
is TI RTOS DSP apps /Debian for his class
Part of the problem is the SDK documents which describe RPMsg and Remote Proc 
were shuffled around for some reason
I saw a panic post in this group about preserving some wiki data I hope its not 
this data I am grabbing everything I can related including TRM
Bottom line you can do anything you want in SDK with any core and the Docs are 
Gonzo good 
 I'm not seeing the OP even responding and dont know why they didnt dig deeper 
maybe they waiting for you to code it all up LOL
I see no value in confusing anyone more in here except a summary after this 
post to help the students and Professor
You are confusing me abit about what you have working  probally because I have 
not digested all the docs I found and digested your comments and replys which 
are very generous
Give me a day to digest the SDK provided docs and email me directly if you have 
questions I feel confident enough to buy a board probally AI and play with SDK 
Linux and TI RTOS examples with and without JTAG and CCS  we have different 
goals I dont need Debian but you and me are good if you need me or think I can 
help your doing quite well.
reply directlyto lazarman and  please watch that you dont share private stuff 
in this group like the recruiter story you posted i  this group that doesnt 
belong in here  Im sure that was an accident but I feel I have found a friend 
and appreciate your feedback.
Lets regroup for a day and do our homework so we can summarize our research I 
need HW so I am envious you are a step ahead but I have more than enough docs 
to realize this is very well documented 
Cheers my friend
Mark
On Thursday, February 18, 2021, 07:05:35 PM CST, jeff@gmail.com 
 wrote:  
 
 No, not yet Mark,.. wa  wa
This was Debian<->IPU (built on TI SDK, but loaded to IPU via Debian 
RPROC).Looks like Debian can load IPU exe's to the IPU's via REMOTEPROC and 
then exchange messages (?via RPMSG?).I tried the IPU , because I could see in 
the IPU ex02 IPC code where the resource table appears to be getting 
populated/initialized.  I couldn't find evidence of resource_table init within 
DSP code in ex02, only that space was allocated in the link map.  So I decided 
to copy over the IPU exe built under the TI RTOS SDK IPU examples to Debian on 
the BB-X15 and try that.  Also there was a stock IPU image running/loaded on 
the

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread Darren Freed 
Gentlemen,

I have been lurking here as a total noob, trying to exploit all the
goodness in the AI.  For my application (University level physiology
project), I've got the AI running well, using one of the PRUs for
deterministic I/O (Thanks to Mark Yoder's PRU Cookbook), but I would love
to be able to get the DSPs going as well.  So please keep up the good work
and let us know what you're able to uncover and get working.

df


On Thu, Feb 18, 2021 at 6:55 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Jeff
>
> I have found much more documentation including how to move and change the
> DSP and M4 carve outs sizes  some of it references the TRM but summarizes
> it for a newb like myself and the three people in this group including you
> that needed it and asked
> There a professor at UIC who needs this data as well his use case is TI
> RTOS DSP apps /Debian for his class
>
> Part of the problem is the SDK documents which describe RPMsg and Remote
> Proc were shuffled around for some reason
>
> I saw a panic post in this group about preserving some wiki data I hope
> its not this data I am grabbing everything I can related including TRM
>
> Bottom line you can do anything you want in SDK with any core and the Docs
> are Gonzo good
>
>  I'm not seeing the OP even responding and dont know why they didnt dig
> deeper maybe they waiting for you to code it all up LOL
>
> I see no value in confusing anyone more in here except a summary after
> this post to help the students and Professor
>
> You are confusing me abit about what you have working  probally because I
> have not digested all the docs I found and digested your comments and
> replys which are very generous
>
> Give me a day to digest the SDK provided docs and email me directly if you
> have questions I feel confident enough to buy a board probally AI and play
> with SDK Linux and TI RTOS examples with and without JTAG and CCS  we have
> different goals I dont need Debian but you and me are good if you need me
> or think I can help your doing quite well.
>
> reply directlyto lazarman and  please watch that you dont share private
> stuff in this group like the recruiter story you posted i  this group that
> doesnt belong in here  Im sure that was an accident but I feel I have found
> a friend and appreciate your feedback.
>
> Lets regroup for a day and do our homework so we can summarize our
> research I need HW so I am envious you are a step ahead but I have more
> than enough docs to realize this is very well documented
>
> Cheers my friend
>
> Mark
>
> On Thursday, February 18, 2021, 07:05:35 PM CST, jeff@gmail.com <
> jeff.and...@gmail.com> wrote:
>
>
> No, not yet Mark,.. wa  wa
>
> This was Debian<->IPU (built on TI SDK, but loaded to IPU via Debian
> RPROC).
> Looks like Debian can load IPU exe's to the IPU's via REMOTEPROC and then
> exchange messages (?via RPMSG?).
> I tried the IPU , because I could see in the IPU ex02 IPC code where the
> resource table appears to be getting populated/initialized.  I couldn't
> find evidence of resource_table init within DSP code in ex02, only that
> space was allocated in the link map.  So I decided to copy over the IPU exe
> built under the TI RTOS SDK IPU examples to Debian on the BB-X15 and try
> that.  Also there was a stock IPU image running/loaded on the BB-X15 Debian
> image.  I'm curious about what that does and where the source code is for
> it...
>
> Haven't yet been able to get the DSP to load via RPROC.Am still
> getting resource_table not found and a '-2' load error when I attempt to
> load the DSP from Debian using RPROC.  I would think the TI IPC SDK
> examples would build properly, so investigating whether the .resource_table
> is getting initialized correctly could be a red herring..  Next-step after
> the resource table maybe to load the same exe on the TI SDK Linux image
> running on the BB-X15.
>
> Not sure what's needed to send printf's from the IPU or DSP to a Linux
> debug console via IPC...
>
> Regards, Jeff
>
>
> On Thursday, February 18, 2021 at 6:39:04 PM UTC-5 lazarman wrote:
>
> Wonderful.
>
> So for myself and everyone else in group understanding  is this following
> correct?
>
> DSP  to ARM messaging works using Debian and the SDK DSP examples loaded
> on DSP by Linux automatically?
>
> Remoteproc loaded the DSP image from Linux and started it?
>
> For those that don't care for JTAG debugging or don't own one can use
> printf debug is available to debug  their DSP applications?
>
> Anybody wanting to do same can use these DSP examples as a starting point
> look at source code and modify these examples into TI RTOS examples
> assuming they are not already using TI RTOS.
>
> Be wonderful to know how big the shared memory is and where to increase it
> but I think that can be left to the learner.
>
> Thank you for sharing this.
>
>
>
>
>
> Sent from Yahoo Mail on Android
> 
> modify

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread 'Mark Lazarewicz' via BeagleBoard 
 Jeff
I have found much more documentation including how to move and change the DSP 
and M4 carve outs sizes  some of it references the TRM but summarizes it for a 
newb like myself and the three people in this group including you that needed 
it and asked There a professor at UIC who needs this data as well his use case 
is TI RTOS DSP apps /Debian for his class
Part of the problem is the SDK documents which describe RPMsg and Remote Proc 
were shuffled around for some reason
I saw a panic post in this group about preserving some wiki data I hope its not 
this data I am grabbing everything I can related including TRM
Bottom line you can do anything you want in SDK with any core and the Docs are 
Gonzo good 
 I'm not seeing the OP even responding and dont know why they didnt dig deeper 
maybe they waiting for you to code it all up LOL
I see no value in confusing anyone more in here except a summary after this 
post to help the students and Professor
You are confusing me abit about what you have working  probally because I have 
not digested all the docs I found and digested your comments and replys which 
are very generous
Give me a day to digest the SDK provided docs and email me directly if you have 
questions I feel confident enough to buy a board probally AI and play with SDK 
Linux and TI RTOS examples with and without JTAG and CCS  we have different 
goals I dont need Debian but you and me are good if you need me or think I can 
help your doing quite well.
reply directlyto lazarman and  please watch that you dont share private stuff 
in this group like the recruiter story you posted i  this group that doesnt 
belong in here  Im sure that was an accident but I feel I have found a friend 
and appreciate your feedback.
Lets regroup for a day and do our homework so we can summarize our research I 
need HW so I am envious you are a step ahead but I have more than enough docs 
to realize this is very well documented 
Cheers my friend
Mark
On Thursday, February 18, 2021, 07:05:35 PM CST, jeff@gmail.com 
 wrote:  
 
 No, not yet Mark,.. wa  wa
This was Debian<->IPU (built on TI SDK, but loaded to IPU via Debian 
RPROC).Looks like Debian can load IPU exe's to the IPU's via REMOTEPROC and 
then exchange messages (?via RPMSG?).I tried the IPU , because I could see in 
the IPU ex02 IPC code where the resource table appears to be getting 
populated/initialized.  I couldn't find evidence of resource_table init within 
DSP code in ex02, only that space was allocated in the link map.  So I decided 
to copy over the IPU exe built under the TI RTOS SDK IPU examples to Debian on 
the BB-X15 and try that.  Also there was a stock IPU image running/loaded on 
the BB-X15 Debian image.  I'm curious about what that does and where the source 
code is for it...  
Haven't yet been able to get the DSP to load via RPROC.    Am still getting 
resource_table not found and a '-2' load error when I attempt to load the DSP 
from Debian using RPROC.  I would think the TI IPC SDK examples would build 
properly, so investigating whether the .resource_table is getting initialized 
correctly could be a red herring..  Next-step after the resource table maybe to 
load the same exe on the TI SDK Linux image running on the BB-X15.
Not sure what's needed to send printf's from the IPU or DSP to a Linux debug 
console via IPC... 
Regards, Jeff

On Thursday, February 18, 2021 at 6:39:04 PM UTC-5 lazarman wrote:

Wonderful.
So for myself and everyone else in group understanding  is this following 
correct?
DSP  to ARM messaging works using Debian and the SDK DSP examples loaded on DSP 
by Linux automatically?
Remoteproc loaded the DSP image from Linux and started it?
For those that don't care for JTAG debugging or don't own one can use printf 
debug is available to debug  their DSP applications?
Anybody wanting to do same can use these DSP examples as a starting point  look 
at source code and modify these examples into TI RTOS examples assuming they 
are not already using TI RTOS.
Be wonderful to know how big the shared memory is and where to increase it but 
I think that can be left to the learner. 
Thank you for sharing this.




Sent from Yahoo Mail on Android modify 
 


  On Thu, Feb 18, 2021 at 4:56 PM, jeff@gmail.com 
wrote:  

I got lazy...
Was trying to figure out how to build app_host (part of the ex02_message) 
example natively on the BBB, when I said... Won't hurt anything if I try 
running it the exe built under TI SDK Linux on the BB-X15.At first, I got the 
following, when I tried to run as Debian, but then when logged in as su, it 
just worked. 
Now am scratching my head as to why this works..  The API's between the app and 
remoteproc/rpmsg/vring buffers are the same???


debian@beaglebone:~/ipc-starter$ ./app_host -l--> main:Processor ListIpc_start: 
LAD_connect() failed: 4Error: main_host.c, line 198: Ipc_start failed
But then su.
debian@beaglebone:~/ipc-starter$ suPassword: 

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
No, not yet Mark,.. wa  wa

This was Debian<->IPU (built on TI SDK, but loaded to IPU via Debian RPROC).
Looks like Debian can load IPU exe's to the IPU's via REMOTEPROC and then 
exchange messages (?via RPMSG?).
I tried the IPU , because I could see in the IPU ex02 IPC code where the 
resource table appears to be getting populated/initialized.  I couldn't 
find evidence of resource_table init within DSP code in ex02, only that 
space was allocated in the link map.  So I decided to copy over the IPU exe 
built under the TI RTOS SDK IPU examples to Debian on the BB-X15 and try 
that.  Also there was a stock IPU image running/loaded on the BB-X15 Debian 
image.  I'm curious about what that does and where the source code is for 
it...  

Haven't yet been able to get the DSP to load via RPROC.Am still getting 
resource_table not found and a '-2' load error when I attempt to load the 
DSP from Debian using RPROC.  I would think the TI IPC SDK examples would 
build properly, so investigating whether the .resource_table is getting 
initialized correctly could be a red herring..  Next-step after the 
resource table maybe to load the same exe on the TI SDK Linux image running 
on the BB-X15.

Not sure what's needed to send printf's from the IPU or DSP to a Linux 
debug console via IPC... 

Regards, Jeff


On Thursday, February 18, 2021 at 6:39:04 PM UTC-5 lazarman wrote:

> Wonderful.
>
> So for myself and everyone else in group understanding  is this following 
> correct?
>
> DSP  to ARM messaging works using Debian and the SDK DSP examples loaded 
> on DSP by Linux automatically?
>
> Remoteproc loaded the DSP image from Linux and started it?
>
> For those that don't care for JTAG debugging or don't own one can use 
> printf debug is available to debug  their DSP applications?
>
> Anybody wanting to do same can use these DSP examples as a starting point  
> look at source code and modify these examples into TI RTOS examples 
> assuming they are not already using TI RTOS.
>
> Be wonderful to know how big the shared memory is and where to increase it 
> but I think that can be left to the learner. 
>
> Thank you for sharing this.
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
> modify 
>
> On Thu, Feb 18, 2021 at 4:56 PM, jeff@gmail.com
>  wrote:
>
> I got lazy...
>
> Was trying to figure out how to build app_host (part of the ex02_message) 
> example natively on the BBB, when I said... Won't hurt anything if I try 
> running it the exe built under TI SDK Linux on the BB-X15.
> At first, I got the following, when I tried to run as Debian, but then 
> when logged in as su, it just worked. 
>
> Now am scratching my head as to why this works..  The API's between the 
> app and remoteproc/rpmsg/vring buffers are the same???
>
>
>
> debian@beaglebone:~/ipc-starter$ ./app_host -l
> --> main:
> Processor List
> Ipc_start: LAD_connect() failed: 4
> Error: main_host.c, line 198: Ipc_start failed
>
> But then su.
>
> debian@beaglebone:~/ipc-starter$ su
> Password: 
> root@beaglebone:/home/debian/ipc-starter# ./app_host -l
> --> main:
> Processor List
> procId=0, procName=HOST
> procId=1, procName=IPU2
> procId=2, procName=IPU1
> procId=3, procName=DSP2
> procId=4, procName=DSP1
>
>
> root@beaglebone:/home/debian/ipc-starter# ./app_host IPU1
> --> main:
> --> Main_main:
> --> App_create:
> App_create: Host is ready
> <-- App_create:
> --> App_exec:
> App_exec: sending message 1
> App_exec: sending message 2
> App_exec: sending message 3
> App_exec: message received, sending message 4
> App_exec: message received, sending message 5
> App_exec: message received, sending message 6
> App_exec: message received, sending message 7
> App_exec: message received, sending message 8
> App_exec: message received, sending message 9
> App_exec: message received, sending message 10
> App_exec: message received, sending message 11
> App_exec: message received, sending message 12
> App_exec: message received, sending message 13
> App_exec: message received, sending message 14
> App_exec: message received, sending message 15
> App_exec: message received
> App_exec: message received
> App_exec: message received
> <-- App_exec: 0
> --> App_delete:
> <-- App_delete:
> <-- Main_main:
> <-- main:
> root@beaglebone:/home/debian/ipc-starter# 
>
>
>
>
> On Thursday, February 18, 2021 at 1:58:45 PM UTC-5 lazarman wrote:
>
> Hi Jeff
>
> Yes do the homework agreed.  One has to understand the RTOS support isn't 
> beagle.org and e2e isn't for the Debian  kernel I think that's clear to 
> most people except beginners. I agree both this group and e2e are great 
> resources and this group has done a lot to promote learning Linux. There is 
> a gap for learning RTOS especially in colleges. Both operating system  have 
> there merits is my message.
>
> Thanks 
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread 'Mark Lazarewicz' via BeagleBoard 
Wonderful.
So for myself and everyone else in group understanding  is this following 
correct?
DSP  to ARM messaging works using Debian and the SDK DSP examples loaded on DSP 
by Linux automatically?
Remoteproc loaded the DSP image from Linux and started it?
For those that don't care for JTAG debugging or don't own one can use printf 
debug is available to debug  their DSP applications?
Anybody wanting to do same can use these DSP examples as a starting point  look 
at source code and modify these examples into TI RTOS examples assuming they 
are not already using TI RTOS.
Be wonderful to know how big the shared memory is and where to increase it but 
I think that can be left to the learner. 
Thank you for sharing this.




Sent from Yahoo Mail on Android modify 
 
  On Thu, Feb 18, 2021 at 4:56 PM, jeff@gmail.com 
wrote:   I got lazy...
Was trying to figure out how to build app_host (part of the ex02_message) 
example natively on the BBB, when I said... Won't hurt anything if I try 
running it the exe built under TI SDK Linux on the BB-X15.At first, I got the 
following, when I tried to run as Debian, but then when logged in as su, it 
just worked. 
Now am scratching my head as to why this works..  The API's between the app and 
remoteproc/rpmsg/vring buffers are the same???


debian@beaglebone:~/ipc-starter$ ./app_host -l--> main:Processor ListIpc_start: 
LAD_connect() failed: 4Error: main_host.c, line 198: Ipc_start failed
But then su.
debian@beaglebone:~/ipc-starter$ suPassword: 
root@beaglebone:/home/debian/ipc-starter# ./app_host -l--> main:Processor List  
  procId=0, procName=HOST    procId=1, procName=IPU2    procId=2, procName=IPU1 
   procId=3, procName=DSP2    procId=4, procName=DSP1

root@beaglebone:/home/debian/ipc-starter# ./app_host IPU1--> main:--> 
Main_main:--> App_create:App_create: Host is ready<-- App_create:--> 
App_exec:App_exec: sending message 1App_exec: sending message 2App_exec: 
sending message 3App_exec: message received, sending message 4App_exec: message 
received, sending message 5App_exec: message received, sending message 
6App_exec: message received, sending message 7App_exec: message received, 
sending message 8App_exec: message received, sending message 9App_exec: message 
received, sending message 10App_exec: message received, sending message 
11App_exec: message received, sending message 12App_exec: message received, 
sending message 13App_exec: message received, sending message 14App_exec: 
message received, sending message 15App_exec: message receivedApp_exec: message 
receivedApp_exec: message received<-- App_exec: 0--> App_delete:<-- 
App_delete:<-- Main_main:<-- main:root@beaglebone:/home/debian/ipc-starter# 



On Thursday, February 18, 2021 at 1:58:45 PM UTC-5 lazarman wrote:

Hi Jeff
Yes do the homework agreed.  One has to understand the RTOS support isn't 
beagle.org and e2e isn't for the Debian  kernel I think that's clear to most 
people except beginners. I agree both this group and e2e are great resources 
and this group has done a lot to promote learning Linux. There is a gap for 
learning RTOS especially in colleges. Both operating system  have there merits 
is my message.
Thanks 

Sent from Yahoo Mail on Android 
 
  On Thu, Feb 18, 2021 at 12:39 PM, jeff@gmail.com 
wrote:  

That recruiter is a disgrace for such an unconscionable, absurd statement!  
Many of us are in that boat and most reputable employers allow their employees 
time-off to deal with taking care of family members.  It's probably just as 
well that they told you that in that getting further along in the process with 
them probably would have caused even more frustration...
I know, it's difficult on here at times, but my experience is, if you do the 
groundwork first, either/both BB.org and/or the community members will help.  
Have gotten a lot of help on here previously..


On Thursday, February 18, 2021 at 1:25:18 PM UTC-5 lazarman wrote:

Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes sense 
not interested in AI. I agree about Beagle forum between us we have enough 
experience to solve this.
Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
employment taking care of mom rules out any contract jobs he says they want 
recent experience. Lol 30 plus years experience can't get no respect especially 
in the open source forum haha
Stay safe


Sent from Yahoo Mail on Android 
 
  On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com 
wrote:   

Thanks Mark for your words of wizdom on here and in our email chats!  You 
helped me look for the linker command file for the DSP build. The linker is 
allocating space for the resource table, but I don't see where the server_dsp1 
code is statically initializing the table in the RTOS SDK linux build 
(DRA7XX_linux_elf build for ex02_message).  I just need to make sure that the 
DSP1 build's resource table is getting initialized and retry and see if the 
remoteproc error goes away on

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
debian@beaglebone:~/ipc-starter$ cat /etc/dogtag
BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06
debian@beaglebone:~/ipc-starter$ uname -r
4.14.108-ti-r131

processor_sdk_rtos_am57xx_6_03_00_106
/ti/ipc_3_50_04_08/examples/DRA7XX_linux_elf/ex02_messageq$ 
/ti-processor-sdk-linux-am57xx-evm-06.03.00.106$ 


On Thursday, February 18, 2021 at 5:48:04 PM UTC-5 jeff@gmail.com wrote:

> I got lazy...
>
> Was trying to figure out how to build app_host (part of the ex02_message) 
> example natively on the BBB, when I said... Won't hurt anything if I try 
> running it the exe built under TI SDK Linux on the BB-X15.
> At first, I got the following, when I tried to run as Debian, but then 
> when logged in as su, it just worked. 
>
> Now am scratching my head as to why this works..  The API's between the 
> app and remoteproc/rpmsg/vring buffers are the same???
>
>
>
> debian@beaglebone:~/ipc-starter$ ./app_host -l
> --> main:
> Processor List
> Ipc_start: LAD_connect() failed: 4
> Error: main_host.c, line 198: Ipc_start failed
>
> But then su.
>
> debian@beaglebone:~/ipc-starter$ su
> Password: 
> root@beaglebone:/home/debian/ipc-starter# ./app_host -l
> --> main:
> Processor List
> procId=0, procName=HOST
> procId=1, procName=IPU2
> procId=2, procName=IPU1
> procId=3, procName=DSP2
> procId=4, procName=DSP1
>
>
> root@beaglebone:/home/debian/ipc-starter# ./app_host IPU1
> --> main:
> --> Main_main:
> --> App_create:
> App_create: Host is ready
> <-- App_create:
> --> App_exec:
> App_exec: sending message 1
> App_exec: sending message 2
> App_exec: sending message 3
> App_exec: message received, sending message 4
> App_exec: message received, sending message 5
> App_exec: message received, sending message 6
> App_exec: message received, sending message 7
> App_exec: message received, sending message 8
> App_exec: message received, sending message 9
> App_exec: message received, sending message 10
> App_exec: message received, sending message 11
> App_exec: message received, sending message 12
> App_exec: message received, sending message 13
> App_exec: message received, sending message 14
> App_exec: message received, sending message 15
> App_exec: message received
> App_exec: message received
> App_exec: message received
> <-- App_exec: 0
> --> App_delete:
> <-- App_delete:
> <-- Main_main:
> <-- main:
> root@beaglebone:/home/debian/ipc-starter# 
>
>
>
>
> On Thursday, February 18, 2021 at 1:58:45 PM UTC-5 lazarman wrote:
>
>> Hi Jeff
>>
>> Yes do the homework agreed.  One has to understand the RTOS support isn't 
>> beagle.org and e2e isn't for the Debian  kernel I think that's clear to 
>> most people except beginners. I agree both this group and e2e are great 
>> resources and this group has done a lot to promote learning Linux. There is 
>> a gap for learning RTOS especially in colleges. Both operating system  have 
>> there merits is my message.
>>
>> Thanks 
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Thu, Feb 18, 2021 at 12:39 PM, jeff@gmail.com
>>  wrote:
>>
>> That recruiter is a disgrace for such an unconscionable, absurd 
>> statement!  Many of us are in that boat and most reputable employers allow 
>> their employees time-off to deal with taking care of family members.  It's 
>> probably just as well that they told you that in that getting further along 
>> in the process with them probably would have caused even more frustration...
>>
>> I know, it's difficult on here at times, but my experience is, if you do 
>> the groundwork first, either/both BB.org and/or the community members will 
>> help.  Have gotten a lot of help on here previously..
>>
>>
>>
>> On Thursday, February 18, 2021 at 1:25:18 PM UTC-5 lazarman wrote:
>>
>> Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes 
>> sense not interested in AI. I agree about Beagle forum between us we have 
>> enough experience to solve this.
>>
>> Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
>> employment taking care of mom rules out any contract jobs he says they want 
>> recent experience. Lol 30 plus years experience can't get no respect 
>> especially in the open source forum haha
>>
>> Stay safe
>>
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com
>>  wrote:
>>
>> Thanks Mark for your words of wizdom on here and in our email chats!  You 
>> helped me look for the linker command file for the DSP build. The linker is 
>> allocating space for the resource table, but I don't see where the 
>> server_dsp1 code is statically initializing the table in the RTOS SDK linux 
>> build (DRA7XX_linux_elf build for ex02_message).  I just need to make sure 
>> that the DSP1 build's resource table is getting initialized and retry and 
>> see if the remoteproc error goes away on the BB.ORG latest

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
debian@beaglebone:~/ipc-starter$ cat /etc/dogtag
BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06
debian@beaglebone:~/ipc-starter$ uname -r
4.14.108-ti-r131

/ti/ipc_3_50_04_08/examples/DRA7XX_linux_elf/ex02_messageq$ 
/ti-processor-sdk-linux-am57xx-evm-06.03.00.106$ 

On Thursday, February 18, 2021 at 5:48:04 PM UTC-5 jeff@gmail.com wrote:

> I got lazy...
>
> Was trying to figure out how to build app_host (part of the ex02_message) 
> example natively on the BBB, when I said... Won't hurt anything if I try 
> running it the exe built under TI SDK Linux on the BB-X15.
> At first, I got the following, when I tried to run as Debian, but then 
> when logged in as su, it just worked. 
>
> Now am scratching my head as to why this works..  The API's between the 
> app and remoteproc/rpmsg/vring buffers are the same???
>
>
>
> debian@beaglebone:~/ipc-starter$ ./app_host -l
> --> main:
> Processor List
> Ipc_start: LAD_connect() failed: 4
> Error: main_host.c, line 198: Ipc_start failed
>
> But then su.
>
> debian@beaglebone:~/ipc-starter$ su
> Password: 
> root@beaglebone:/home/debian/ipc-starter# ./app_host -l
> --> main:
> Processor List
> procId=0, procName=HOST
> procId=1, procName=IPU2
> procId=2, procName=IPU1
> procId=3, procName=DSP2
> procId=4, procName=DSP1
>
>
> root@beaglebone:/home/debian/ipc-starter# ./app_host IPU1
> --> main:
> --> Main_main:
> --> App_create:
> App_create: Host is ready
> <-- App_create:
> --> App_exec:
> App_exec: sending message 1
> App_exec: sending message 2
> App_exec: sending message 3
> App_exec: message received, sending message 4
> App_exec: message received, sending message 5
> App_exec: message received, sending message 6
> App_exec: message received, sending message 7
> App_exec: message received, sending message 8
> App_exec: message received, sending message 9
> App_exec: message received, sending message 10
> App_exec: message received, sending message 11
> App_exec: message received, sending message 12
> App_exec: message received, sending message 13
> App_exec: message received, sending message 14
> App_exec: message received, sending message 15
> App_exec: message received
> App_exec: message received
> App_exec: message received
> <-- App_exec: 0
> --> App_delete:
> <-- App_delete:
> <-- Main_main:
> <-- main:
> root@beaglebone:/home/debian/ipc-starter# 
>
>
>
>
> On Thursday, February 18, 2021 at 1:58:45 PM UTC-5 lazarman wrote:
>
>> Hi Jeff
>>
>> Yes do the homework agreed.  One has to understand the RTOS support isn't 
>> beagle.org and e2e isn't for the Debian  kernel I think that's clear to 
>> most people except beginners. I agree both this group and e2e are great 
>> resources and this group has done a lot to promote learning Linux. There is 
>> a gap for learning RTOS especially in colleges. Both operating system  have 
>> there merits is my message.
>>
>> Thanks 
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Thu, Feb 18, 2021 at 12:39 PM, jeff@gmail.com
>>  wrote:
>>
>> That recruiter is a disgrace for such an unconscionable, absurd 
>> statement!  Many of us are in that boat and most reputable employers allow 
>> their employees time-off to deal with taking care of family members.  It's 
>> probably just as well that they told you that in that getting further along 
>> in the process with them probably would have caused even more frustration...
>>
>> I know, it's difficult on here at times, but my experience is, if you do 
>> the groundwork first, either/both BB.org and/or the community members will 
>> help.  Have gotten a lot of help on here previously..
>>
>>
>>
>> On Thursday, February 18, 2021 at 1:25:18 PM UTC-5 lazarman wrote:
>>
>> Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes 
>> sense not interested in AI. I agree about Beagle forum between us we have 
>> enough experience to solve this.
>>
>> Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
>> employment taking care of mom rules out any contract jobs he says they want 
>> recent experience. Lol 30 plus years experience can't get no respect 
>> especially in the open source forum haha
>>
>> Stay safe
>>
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com
>>  wrote:
>>
>> Thanks Mark for your words of wizdom on here and in our email chats!  You 
>> helped me look for the linker command file for the DSP build. The linker is 
>> allocating space for the resource table, but I don't see where the 
>> server_dsp1 code is statically initializing the table in the RTOS SDK linux 
>> build (DRA7XX_linux_elf build for ex02_message).  I just need to make sure 
>> that the DSP1 build's resource table is getting initialized and retry and 
>> see if the remoteproc error goes away on the BB.ORG latest BB-X15 build 
>> which I am loading all of

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
debian@beaglebone:~/ipc-starter$ cat /etc/dogtag 
BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06
debian@beaglebone:~/ipc-starter$ uname -r
4.14.108-ti-r131


On Thursday, February 18, 2021 at 5:48:04 PM UTC-5 jeff@gmail.com wrote:

> I got lazy...
>
> Was trying to figure out how to build app_host (part of the ex02_message) 
> example natively on the BBB, when I said... Won't hurt anything if I try 
> running it the exe built under TI SDK Linux on the BB-X15.
> At first, I got the following, when I tried to run as Debian, but then 
> when logged in as su, it just worked. 
>
> Now am scratching my head as to why this works..  The API's between the 
> app and remoteproc/rpmsg/vring buffers are the same???
>
>
>
> debian@beaglebone:~/ipc-starter$ ./app_host -l
> --> main:
> Processor List
> Ipc_start: LAD_connect() failed: 4
> Error: main_host.c, line 198: Ipc_start failed
>
> But then su.
>
> debian@beaglebone:~/ipc-starter$ su
> Password: 
> root@beaglebone:/home/debian/ipc-starter# ./app_host -l
> --> main:
> Processor List
> procId=0, procName=HOST
> procId=1, procName=IPU2
> procId=2, procName=IPU1
> procId=3, procName=DSP2
> procId=4, procName=DSP1
>
>
> root@beaglebone:/home/debian/ipc-starter# ./app_host IPU1
> --> main:
> --> Main_main:
> --> App_create:
> App_create: Host is ready
> <-- App_create:
> --> App_exec:
> App_exec: sending message 1
> App_exec: sending message 2
> App_exec: sending message 3
> App_exec: message received, sending message 4
> App_exec: message received, sending message 5
> App_exec: message received, sending message 6
> App_exec: message received, sending message 7
> App_exec: message received, sending message 8
> App_exec: message received, sending message 9
> App_exec: message received, sending message 10
> App_exec: message received, sending message 11
> App_exec: message received, sending message 12
> App_exec: message received, sending message 13
> App_exec: message received, sending message 14
> App_exec: message received, sending message 15
> App_exec: message received
> App_exec: message received
> App_exec: message received
> <-- App_exec: 0
> --> App_delete:
> <-- App_delete:
> <-- Main_main:
> <-- main:
> root@beaglebone:/home/debian/ipc-starter# 
>
>
>
>
> On Thursday, February 18, 2021 at 1:58:45 PM UTC-5 lazarman wrote:
>
>> Hi Jeff
>>
>> Yes do the homework agreed.  One has to understand the RTOS support isn't 
>> beagle.org and e2e isn't for the Debian  kernel I think that's clear to 
>> most people except beginners. I agree both this group and e2e are great 
>> resources and this group has done a lot to promote learning Linux. There is 
>> a gap for learning RTOS especially in colleges. Both operating system  have 
>> there merits is my message.
>>
>> Thanks 
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Thu, Feb 18, 2021 at 12:39 PM, jeff@gmail.com
>>  wrote:
>>
>> That recruiter is a disgrace for such an unconscionable, absurd 
>> statement!  Many of us are in that boat and most reputable employers allow 
>> their employees time-off to deal with taking care of family members.  It's 
>> probably just as well that they told you that in that getting further along 
>> in the process with them probably would have caused even more frustration...
>>
>> I know, it's difficult on here at times, but my experience is, if you do 
>> the groundwork first, either/both BB.org and/or the community members will 
>> help.  Have gotten a lot of help on here previously..
>>
>>
>>
>> On Thursday, February 18, 2021 at 1:25:18 PM UTC-5 lazarman wrote:
>>
>> Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes 
>> sense not interested in AI. I agree about Beagle forum between us we have 
>> enough experience to solve this.
>>
>> Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
>> employment taking care of mom rules out any contract jobs he says they want 
>> recent experience. Lol 30 plus years experience can't get no respect 
>> especially in the open source forum haha
>>
>> Stay safe
>>
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com
>>  wrote:
>>
>> Thanks Mark for your words of wizdom on here and in our email chats!  You 
>> helped me look for the linker command file for the DSP build. The linker is 
>> allocating space for the resource table, but I don't see where the 
>> server_dsp1 code is statically initializing the table in the RTOS SDK linux 
>> build (DRA7XX_linux_elf build for ex02_message).  I just need to make sure 
>> that the DSP1 build's resource table is getting initialized and retry and 
>> see if the remoteproc error goes away on the BB.ORG latest BB-X15 build 
>> which I am loading all of the DSP/IPU images (built under TI SDK RTOS) onto.
>>
>> I did notice that the IPU code under the same example

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
I got lazy...

Was trying to figure out how to build app_host (part of the ex02_message) 
example natively on the BBB, when I said... Won't hurt anything if I try 
running it the exe built under TI SDK Linux on the BB-X15.
At first, I got the following, when I tried to run as Debian, but then when 
logged in as su, it just worked. 

Now am scratching my head as to why this works..  The API's between the app 
and remoteproc/rpmsg/vring buffers are the same???



debian@beaglebone:~/ipc-starter$ ./app_host -l
--> main:
Processor List
Ipc_start: LAD_connect() failed: 4
Error: main_host.c, line 198: Ipc_start failed

But then su.

debian@beaglebone:~/ipc-starter$ su
Password: 
root@beaglebone:/home/debian/ipc-starter# ./app_host -l
--> main:
Processor List
procId=0, procName=HOST
procId=1, procName=IPU2
procId=2, procName=IPU1
procId=3, procName=DSP2
procId=4, procName=DSP1


root@beaglebone:/home/debian/ipc-starter# ./app_host IPU1
--> main:
--> Main_main:
--> App_create:
App_create: Host is ready
<-- App_create:
--> App_exec:
App_exec: sending message 1
App_exec: sending message 2
App_exec: sending message 3
App_exec: message received, sending message 4
App_exec: message received, sending message 5
App_exec: message received, sending message 6
App_exec: message received, sending message 7
App_exec: message received, sending message 8
App_exec: message received, sending message 9
App_exec: message received, sending message 10
App_exec: message received, sending message 11
App_exec: message received, sending message 12
App_exec: message received, sending message 13
App_exec: message received, sending message 14
App_exec: message received, sending message 15
App_exec: message received
App_exec: message received
App_exec: message received
<-- App_exec: 0
--> App_delete:
<-- App_delete:
<-- Main_main:
<-- main:
root@beaglebone:/home/debian/ipc-starter# 




On Thursday, February 18, 2021 at 1:58:45 PM UTC-5 lazarman wrote:

> Hi Jeff
>
> Yes do the homework agreed.  One has to understand the RTOS support isn't 
> beagle.org and e2e isn't for the Debian  kernel I think that's clear to 
> most people except beginners. I agree both this group and e2e are great 
> resources and this group has done a lot to promote learning Linux. There is 
> a gap for learning RTOS especially in colleges. Both operating system  have 
> there merits is my message.
>
> Thanks 
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Thu, Feb 18, 2021 at 12:39 PM, jeff@gmail.com
>  wrote:
>
> That recruiter is a disgrace for such an unconscionable, absurd 
> statement!  Many of us are in that boat and most reputable employers allow 
> their employees time-off to deal with taking care of family members.  It's 
> probably just as well that they told you that in that getting further along 
> in the process with them probably would have caused even more frustration...
>
> I know, it's difficult on here at times, but my experience is, if you do 
> the groundwork first, either/both BB.org and/or the community members will 
> help.  Have gotten a lot of help on here previously..
>
>
>
> On Thursday, February 18, 2021 at 1:25:18 PM UTC-5 lazarman wrote:
>
> Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes 
> sense not interested in AI. I agree about Beagle forum between us we have 
> enough experience to solve this.
>
> Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
> employment taking care of mom rules out any contract jobs he says they want 
> recent experience. Lol 30 plus years experience can't get no respect 
> especially in the open source forum haha
>
> Stay safe
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com
>  wrote:
>
> Thanks Mark for your words of wizdom on here and in our email chats!  You 
> helped me look for the linker command file for the DSP build. The linker is 
> allocating space for the resource table, but I don't see where the 
> server_dsp1 code is statically initializing the table in the RTOS SDK linux 
> build (DRA7XX_linux_elf build for ex02_message).  I just need to make sure 
> that the DSP1 build's resource table is getting initialized and retry and 
> see if the remoteproc error goes away on the BB.ORG latest BB-X15 build 
> which I am loading all of the DSP/IPU images (built under TI SDK RTOS) onto.
>
> I did notice that the IPU code under the same example DOES appear to be 
> statically initializing it's resource table, so I thought I'd give loading 
> that a try with remoteproc on the latest Debian image for the BB-X15 by 
> deleting the exitsing IPU load on the Debian image, ln -s to it in 
> /lib/firmware, bind it, and look at the dmesg remoteproc traffic.  I see 
> something interesting here and hopefully promissing!!  Maybe a good 
> intermediate step would be to build the

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread 'Mark Lazarewicz' via BeagleBoard 
Hi Jeff
Yes do the homework agreed.  One has to understand the RTOS support isn't 
beagle.org and e2e isn't for the Debian  kernel I think that's clear to most 
people except beginners. I agree both this group and e2e are great resources 
and this group has done a lot to promote learning Linux. There is a gap for 
learning RTOS especially in colleges. Both operating system  have there merits 
is my message.
Thanks 

Sent from Yahoo Mail on Android 
 
  On Thu, Feb 18, 2021 at 12:39 PM, jeff@gmail.com 
wrote:   That recruiter is a disgrace for such an unconscionable, absurd 
statement!  Many of us are in that boat and most reputable employers allow 
their employees time-off to deal with taking care of family members.  It's 
probably just as well that they told you that in that getting further along in 
the process with them probably would have caused even more frustration...
I know, it's difficult on here at times, but my experience is, if you do the 
groundwork first, either/both BB.org and/or the community members will help.  
Have gotten a lot of help on here previously..


On Thursday, February 18, 2021 at 1:25:18 PM UTC-5 lazarman wrote:

Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes sense 
not interested in AI. I agree about Beagle forum between us we have enough 
experience to solve this.
Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
employment taking care of mom rules out any contract jobs he says they want 
recent experience. Lol 30 plus years experience can't get no respect especially 
in the open source forum haha
Stay safe


Sent from Yahoo Mail on Android 
 
  On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com 
wrote:   

Thanks Mark for your words of wizdom on here and in our email chats!  You 
helped me look for the linker command file for the DSP build. The linker is 
allocating space for the resource table, but I don't see where the server_dsp1 
code is statically initializing the table in the RTOS SDK linux build 
(DRA7XX_linux_elf build for ex02_message).  I just need to make sure that the 
DSP1 build's resource table is getting initialized and retry and see if the 
remoteproc error goes away on the BB.ORG latest BB-X15 build which I am loading 
all of the DSP/IPU images (built under TI SDK RTOS) onto.
I did notice that the IPU code under the same example DOES appear to be 
statically initializing it's resource table, so I thought I'd give loading that 
a try with remoteproc on the latest Debian image for the BB-X15 by deleting the 
exitsing IPU load on the Debian image, ln -s to it in /lib/firmware, bind it, 
and look at the dmesg remoteproc traffic.  I see something interesting here and 
hopefully promissing!!  Maybe a good intermediate step would be to build the 
application side of the ex02 linux application natively on the BB-X15 and see 
if it will pingpong the 14 messages with IPU1 on the Debian build as shown on 
the TI IPC examples.. 
This is just a baby step, but it maybe of interest to someone...
Built the entire ex02_message example under TI SDK RTOS
SCP'ed IPU1 build under example02 on TI SDK to the latest Debian BB-X15 image 
on target.
beagle:/lib/firmware  ln -s /home/debian/ipc-starter/server_ipu1.xem4 
dra7-ipu1-fw.xem4

 echo 5882.ipu > unbind   96  dmesg|grep remote   97  echo 5882.ipu > 
bind   98  dmesg|grep remote

[16120.924223] remoteproc remoteproc0: stopped remote processor 
5882.ipu[16120.924561] remoteproc remoteproc0: releasing 
5882.ipu[16140.961256] remoteproc remoteproc0: 5882.ipu is 
available[16140.969895] remoteproc remoteproc0: powering up 
5882.ipu[16140.969921] remoteproc remoteproc0: Booting fw image 
dra7-ipu1-fw.xem4, size 3984688[16140.989530] remoteproc remoteproc0: 
registered virtio0 (type 7)[16140.989540] remoteproc remoteproc0: remote 
processor 5882.ipu is now up

Anyhow, lots more things to try!!  If I'm able to root out configuration errors 
that are obvious to me, I'll do so and post up here and on E2E (and maybe other 
places) when I'm stuck..
Let me know if you have any advice or want me to try anything!
Jeff

On Monday, February 15, 2021 at 2:23:34 PM UTC-5 lazarman wrote:

 Hi Jeff its not easy to find and is confusing I have bought many boards and 
found out they did not do what I hoped I have an update BBAI is supported that 
is very  good news the EVM is $600Be aware that BBAI rev A1 I think needs a mod 
for JTAG
Just to be clear I am not a linux expert so it appears all cores are supported 
and the Linux on Host ARM is SDK version it may night support all the bells 
Debian has for device drivers 
I have many years using DSP/BIOS and CCS and JTAG at board support level not 
Linux apps
Theres a lot of tools here and RTOS and dual cores isnt something you pick up 
over night
Pleny of good tutorials On learning TI RTOS using CCS and JTAG for a DSP 
application its really complex for a beginner and throw in MPUs and Cache and 
threads and 6

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
That recruiter is a disgrace for such an unconscionable, absurd statement!  
Many of us are in that boat and most reputable employers allow their 
employees time-off to deal with taking care of family members.  It's 
probably just as well that they told you that in that getting further along 
in the process with them probably would have caused even more frustration...

I know, it's difficult on here at times, but my experience is, if you do 
the groundwork first, either/both BB.org and/or the community members will 
help.  Have gotten a lot of help on here previously..



On Thursday, February 18, 2021 at 1:25:18 PM UTC-5 lazarman wrote:

> Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes 
> sense not interested in AI. I agree about Beagle forum between us we have 
> enough experience to solve this.
>
> Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
> employment taking care of mom rules out any contract jobs he says they want 
> recent experience. Lol 30 plus years experience can't get no respect 
> especially in the open source forum haha
>
> Stay safe
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com
>  wrote:
>
> Thanks Mark for your words of wizdom on here and in our email chats!  You 
> helped me look for the linker command file for the DSP build. The linker is 
> allocating space for the resource table, but I don't see where the 
> server_dsp1 code is statically initializing the table in the RTOS SDK linux 
> build (DRA7XX_linux_elf build for ex02_message).  I just need to make sure 
> that the DSP1 build's resource table is getting initialized and retry and 
> see if the remoteproc error goes away on the BB.ORG latest BB-X15 build 
> which I am loading all of the DSP/IPU images (built under TI SDK RTOS) onto.
>
> I did notice that the IPU code under the same example DOES appear to be 
> statically initializing it's resource table, so I thought I'd give loading 
> that a try with remoteproc on the latest Debian image for the BB-X15 by 
> deleting the exitsing IPU load on the Debian image, ln -s to it in 
> /lib/firmware, bind it, and look at the dmesg remoteproc traffic.  I see 
> something interesting here and hopefully promissing!!  Maybe a good 
> intermediate step would be to build the application side of the ex02 linux 
> application natively on the BB-X15 and see if it will pingpong the 14 
> messages with IPU1 on the Debian build as shown on the TI IPC examples..
>  
>
> This is just a baby step, but it maybe of interest to someone...
>
> Built the entire ex02_message example under TI SDK RTOS
>
> SCP'ed IPU1 build under example02 on TI SDK to the latest Debian BB-X15 
> image on target.
>
> beagle:/lib/firmware  ln -s /home/debian/ipc-starter/server_ipu1.xem4 
> dra7-ipu1-fw.xem4
>
>  echo 5882.ipu > unbind
>96  dmesg|grep remote
>97  echo 5882.ipu > bind
>98  dmesg|grep remote
>
>
> [16120.924223] remoteproc remoteproc0: stopped remote processor 
> 5882.ipu
> [16120.924561] remoteproc remoteproc0: releasing 5882.ipu
> [16140.961256] remoteproc remoteproc0: 5882.ipu is available
> [16140.969895] remoteproc remoteproc0: powering up 5882.ipu
> [16140.969921] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, 
> size 3984688
> [16140.989530] remoteproc remoteproc0: registered virtio0 (type 7)
> [16140.989540] remoteproc remoteproc0: remote processor 5882.ipu is 
> now up
>
>
> Anyhow, lots more things to try!!  If I'm able to root out configuration 
> errors that are obvious to me, I'll do so and post up here and on E2E (and 
> maybe other places) when I'm stuck..
>
> Let me know if you have any advice or want me to try anything!
>
> Jeff
>
>
> On Monday, February 15, 2021 at 2:23:34 PM UTC-5 lazarman wrote:
>
> Hi Jeff its not easy to find and is confusing 
> I have bought many boards and found out they did not do what I hoped 
> I have an update BBAI is supported that is very  good news the EVM is $600
> Be aware that BBAI rev A1 I think needs a mod for JTAG
>
> Just to be clear I am not a linux expert so it appears all cores are 
> supported and the Linux on Host ARM is SDK version it may night support all 
> the bells Debian has for device drivers 
>
> I have many years using DSP/BIOS and CCS and JTAG at board support level 
> not Linux apps
>
> Theres a lot of tools here and RTOS and dual cores isnt something you pick 
> up over night
>
> Pleny of good tutorials On learning TI RTOS using CCS and JTAG for a DSP 
> application its really complex for a beginner and throw in MPUs and Cache 
> and threads and 6 cores you really could spend a month learning tools alone
>
> In all fairness a single core AM35X is simpler the beauty is TI has gel 
> scripts to handle all cores and load code internally until MPU is set up 
> for quick and simple apps on ARM and fast learning and low cost the 
>

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread 'Mark Lazarewicz' via BeagleBoard 
Wow let's stay in touch. The AI is cheaper so for a DSP platform it makes sense 
not interested in AI. I agree about Beagle forum between us we have enough 
experience to solve this.
Have a good day I'm a bit blue I had a nasty recruiter tell me my gap in 
employment taking care of mom rules out any contract jobs he says they want 
recent experience. Lol 30 plus years experience can't get no respect especially 
in the open source forum haha
Stay safe


Sent from Yahoo Mail on Android 
 
  On Thu, Feb 18, 2021 at 12:19 PM, jeff@gmail.com 
wrote:   Thanks Mark for your words of wizdom on here and in our email chats!  
You helped me look for the linker command file for the DSP build. The linker is 
allocating space for the resource table, but I don't see where the server_dsp1 
code is statically initializing the table in the RTOS SDK linux build 
(DRA7XX_linux_elf build for ex02_message).  I just need to make sure that the 
DSP1 build's resource table is getting initialized and retry and see if the 
remoteproc error goes away on the BB.ORG latest BB-X15 build which I am loading 
all of the DSP/IPU images (built under TI SDK RTOS) onto.
I did notice that the IPU code under the same example DOES appear to be 
statically initializing it's resource table, so I thought I'd give loading that 
a try with remoteproc on the latest Debian image for the BB-X15 by deleting the 
exitsing IPU load on the Debian image, ln -s to it in /lib/firmware, bind it, 
and look at the dmesg remoteproc traffic.  I see something interesting here and 
hopefully promissing!!  Maybe a good intermediate step would be to build the 
application side of the ex02 linux application natively on the BB-X15 and see 
if it will pingpong the 14 messages with IPU1 on the Debian build as shown on 
the TI IPC examples.. 
This is just a baby step, but it maybe of interest to someone...
Built the entire ex02_message example under TI SDK RTOS
SCP'ed IPU1 build under example02 on TI SDK to the latest Debian BB-X15 image 
on target.
beagle:/lib/firmware  ln -s /home/debian/ipc-starter/server_ipu1.xem4 
dra7-ipu1-fw.xem4

 echo 5882.ipu > unbind   96  dmesg|grep remote   97  echo 5882.ipu > 
bind   98  dmesg|grep remote

[16120.924223] remoteproc remoteproc0: stopped remote processor 
5882.ipu[16120.924561] remoteproc remoteproc0: releasing 
5882.ipu[16140.961256] remoteproc remoteproc0: 5882.ipu is 
available[16140.969895] remoteproc remoteproc0: powering up 
5882.ipu[16140.969921] remoteproc remoteproc0: Booting fw image 
dra7-ipu1-fw.xem4, size 3984688[16140.989530] remoteproc remoteproc0: 
registered virtio0 (type 7)[16140.989540] remoteproc remoteproc0: remote 
processor 5882.ipu is now up

Anyhow, lots more things to try!!  If I'm able to root out configuration errors 
that are obvious to me, I'll do so and post up here and on E2E (and maybe other 
places) when I'm stuck..
Let me know if you have any advice or want me to try anything!
Jeff

On Monday, February 15, 2021 at 2:23:34 PM UTC-5 lazarman wrote:

 Hi Jeff its not easy to find and is confusing I have bought many boards and 
found out they did not do what I hoped I have an update BBAI is supported that 
is very  good news the EVM is $600Be aware that BBAI rev A1 I think needs a mod 
for JTAG
Just to be clear I am not a linux expert so it appears all cores are supported 
and the Linux on Host ARM is SDK version it may night support all the bells 
Debian has for device drivers 
I have many years using DSP/BIOS and CCS and JTAG at board support level not 
Linux apps
Theres a lot of tools here and RTOS and dual cores isnt something you pick up 
over night
Pleny of good tutorials On learning TI RTOS using CCS and JTAG for a DSP 
application its really complex for a beginner and throw in MPUs and Cache and 
threads and 6 cores you really could spend a month learning tools alone
In all fairness a single core AM35X is simpler the beauty is TI has gel scripts 
to handle all cores and load code internally until MPU is set up for quick and 
simple apps on ARM and fast learning and low cost the Debian/Beagle approach is 
probally better its pretty obvious I am RTOS fan (-:
TI has world class tools and good documents
I cant help anyone that insists on mixing the Debian on ARM with TI RTOS on DSP 
I'm not qualified it may be possible
Looks like I was also wrong about omap l138 support for SDK the docs are 
confusing so maybe I buy a BBAI its cheaper than the EVM and play around I miss 
work I took care of mom 3 years she passed away October so I apologize at times 
Im grouchy
Hopefully I helped someone that feels good as well Im excited reading these 
docs so maybe I make a come back!!! and find some work
Regards
The SDK includes a real-time multitasking kernel, FAT file system, network 
communications support, examples, and drivers. The exact content of the SDK 
depends on the capabilities of the device, but all devices share common APIs 
and build on existing proven software

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
Also I believe there was a default IPU image on the Debian BB-X15 image, 
which I overwrote in /lib firmware which remote proc also gave the same 
messages as above (didn't see complaints).  I wonder what that stock IPU 
image does, where more info can be found and if it can be used as a 
starting point for what you all are wanting to do???
 

On Thursday, February 18, 2021 at 12:55:30 PM UTC-5 jeff@gmail.com 
wrote:

> Thanks Mark for your words of wizdom on here and in our email chats!  You 
> helped me look for the linker command file for the DSP build. The linker is 
> allocating space for the resource table, but I don't see where the 
> server_dsp1 code is statically initializing the table in the RTOS SDK linux 
> build (DRA7XX_linux_elf build for ex02_message).  I just need to make sure 
> that the DSP1 build's resource table is getting initialized and retry and 
> see if the remoteproc error goes away on the BB.ORG latest BB-X15 build 
> which I am loading all of the DSP/IPU images (built under TI SDK RTOS) onto.
>
> I did notice that the IPU code under the same example DOES appear to be 
> statically initializing it's resource table, so I thought I'd give loading 
> that a try with remoteproc on the latest Debian image for the BB-X15 by 
> deleting the exitsing IPU load on the Debian image, ln -s to it in 
> /lib/firmware, bind it, and look at the dmesg remoteproc traffic.  I see 
> something interesting here and hopefully promissing!!  Maybe a good 
> intermediate step would be to build the application side of the ex02 linux 
> application natively on the BB-X15 and see if it will pingpong the 14 
> messages with IPU1 on the Debian build as shown on the TI IPC examples..
>  
>
> This is just a baby step, but it maybe of interest to someone...
>
> Built the entire ex02_message example under TI SDK RTOS
>
> SCP'ed IPU1 build under example02 on TI SDK to the latest Debian BB-X15 
> image on target.
>
> beagle:/lib/firmware  ln -s /home/debian/ipc-starter/server_ipu1.xem4 
> dra7-ipu1-fw.xem4
>
>  echo 5882.ipu > unbind
>96  dmesg|grep remote
>97  echo 5882.ipu > bind
>98  dmesg|grep remote
>
>
> [16120.924223] remoteproc remoteproc0: stopped remote processor 
> 5882.ipu
> [16120.924561] remoteproc remoteproc0: releasing 5882.ipu
> [16140.961256] remoteproc remoteproc0: 5882.ipu is available
> [16140.969895] remoteproc remoteproc0: powering up 5882.ipu
> [16140.969921] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, 
> size 3984688
> [16140.989530] remoteproc remoteproc0: registered virtio0 (type 7)
> [16140.989540] remoteproc remoteproc0: remote processor 5882.ipu is 
> now up
>
>
> Anyhow, lots more things to try!!  If I'm able to root out configuration 
> errors that are obvious to me, I'll do so and post up here and on E2E (and 
> maybe other places) when I'm stuck..
>
> Let me know if you have any advice or want me to try anything!
>
> Jeff
>
>
> On Monday, February 15, 2021 at 2:23:34 PM UTC-5 lazarman wrote:
>
>> Hi Jeff its not easy to find and is confusing 
>> I have bought many boards and found out they did not do what I hoped 
>> I have an update BBAI is supported that is very  good news the EVM is $600
>> Be aware that BBAI rev A1 I think needs a mod for JTAG
>>
>> Just to be clear I am not a linux expert so it appears all cores are 
>> supported and the Linux on Host ARM is SDK version it may night support all 
>> the bells Debian has for device drivers 
>>
>> I have many years using DSP/BIOS and CCS and JTAG at board support level 
>> not Linux apps
>>
>> Theres a lot of tools here and RTOS and dual cores isnt something you 
>> pick up over night
>>
>> Pleny of good tutorials On learning TI RTOS using CCS and JTAG for a DSP 
>> application its really complex for a beginner and throw in MPUs and Cache 
>> and threads and 6 cores you really could spend a month learning tools alone
>>
>> In all fairness a single core AM35X is simpler the beauty is TI has gel 
>> scripts to handle all cores and load code internally until MPU is set up 
>> for quick and simple apps on ARM and fast learning and low cost the 
>> Debian/Beagle approach is probally better its pretty obvious I am RTOS fan 
>> (-:
>>
>> TI has world class tools and good documents
>>
>> I cant help anyone that insists on mixing the Debian on ARM with TI RTOS 
>> on DSP I'm not qualified it may be possible
>>
>> Looks like I was also wrong about omap l138 support for SDK the docs are 
>> confusing so maybe I buy a BBAI its cheaper than the EVM and play around I 
>> miss work I took care of mom 3 years she passed away October so I apologize 
>> at times Im grouchy
>>
>> Hopefully I helped someone that feels good as well Im excited reading 
>> these docs so maybe I make a come back!!!
>>  and find some work
>>
>> Regards
>>
>> The SDK includes a real-time multitasking kernel, FAT file system, 
>> network communications support, examples, and drivers. The exact content of 
>> the

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-18 Thread jeff....@gmail.com 
Thanks Mark for your words of wizdom on here and in our email chats!  You 
helped me look for the linker command file for the DSP build. The linker is 
allocating space for the resource table, but I don't see where the 
server_dsp1 code is statically initializing the table in the RTOS SDK linux 
build (DRA7XX_linux_elf build for ex02_message).  I just need to make sure 
that the DSP1 build's resource table is getting initialized and retry and 
see if the remoteproc error goes away on the BB.ORG latest BB-X15 build 
which I am loading all of the DSP/IPU images (built under TI SDK RTOS) onto.

I did notice that the IPU code under the same example DOES appear to be 
statically initializing it's resource table, so I thought I'd give loading 
that a try with remoteproc on the latest Debian image for the BB-X15 by 
deleting the exitsing IPU load on the Debian image, ln -s to it in 
/lib/firmware, bind it, and look at the dmesg remoteproc traffic.  I see 
something interesting here and hopefully promissing!!  Maybe a good 
intermediate step would be to build the application side of the ex02 linux 
application natively on the BB-X15 and see if it will pingpong the 14 
messages with IPU1 on the Debian build as shown on the TI IPC examples..
 

This is just a baby step, but it maybe of interest to someone...

Built the entire ex02_message example under TI SDK RTOS

SCP'ed IPU1 build under example02 on TI SDK to the latest Debian BB-X15 
image on target.

beagle:/lib/firmware  ln -s /home/debian/ipc-starter/server_ipu1.xem4 
dra7-ipu1-fw.xem4

 echo 5882.ipu > unbind
   96  dmesg|grep remote
   97  echo 5882.ipu > bind
   98  dmesg|grep remote


[16120.924223] remoteproc remoteproc0: stopped remote processor 5882.ipu
[16120.924561] remoteproc remoteproc0: releasing 5882.ipu
[16140.961256] remoteproc remoteproc0: 5882.ipu is available
[16140.969895] remoteproc remoteproc0: powering up 5882.ipu
[16140.969921] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, 
size 3984688
[16140.989530] remoteproc remoteproc0: registered virtio0 (type 7)
[16140.989540] remoteproc remoteproc0: remote processor 5882.ipu is now 
up


Anyhow, lots more things to try!!  If I'm able to root out configuration 
errors that are obvious to me, I'll do so and post up here and on E2E (and 
maybe other places) when I'm stuck..

Let me know if you have any advice or want me to try anything!

Jeff


On Monday, February 15, 2021 at 2:23:34 PM UTC-5 lazarman wrote:

> Hi Jeff its not easy to find and is confusing 
> I have bought many boards and found out they did not do what I hoped 
> I have an update BBAI is supported that is very  good news the EVM is $600
> Be aware that BBAI rev A1 I think needs a mod for JTAG
>
> Just to be clear I am not a linux expert so it appears all cores are 
> supported and the Linux on Host ARM is SDK version it may night support all 
> the bells Debian has for device drivers 
>
> I have many years using DSP/BIOS and CCS and JTAG at board support level 
> not Linux apps
>
> Theres a lot of tools here and RTOS and dual cores isnt something you pick 
> up over night
>
> Pleny of good tutorials On learning TI RTOS using CCS and JTAG for a DSP 
> application its really complex for a beginner and throw in MPUs and Cache 
> and threads and 6 cores you really could spend a month learning tools alone
>
> In all fairness a single core AM35X is simpler the beauty is TI has gel 
> scripts to handle all cores and load code internally until MPU is set up 
> for quick and simple apps on ARM and fast learning and low cost the 
> Debian/Beagle approach is probally better its pretty obvious I am RTOS fan 
> (-:
>
> TI has world class tools and good documents
>
> I cant help anyone that insists on mixing the Debian on ARM with TI RTOS 
> on DSP I'm not qualified it may be possible
>
> Looks like I was also wrong about omap l138 support for SDK the docs are 
> confusing so maybe I buy a BBAI its cheaper than the EVM and play around I 
> miss work I took care of mom 3 years she passed away October so I apologize 
> at times Im grouchy
>
> Hopefully I helped someone that feels good as well Im excited reading 
> these docs so maybe I make a come back!!!
>  and find some work
>
> Regards
>
> The SDK includes a real-time multitasking kernel, FAT file system, network 
> communications support, examples, and drivers. The exact content of the SDK 
> depends on the capabilities of the device, but all devices share common 
> APIs and build on existing proven software components to ensure reliability 
> and quality. The software components are fully tested to ensure that they 
> work together with TI’s Code Composer Studio integrated development 
> environment.
>
> Supported Platforms
>
> 
> Platform Supported Devices Supported EVMs
> AM57x  AM5728 
> , AM5726 
> , AM5729 
>

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-15 Thread 'Mark Lazarewicz' via BeagleBoard 
 Hi Jeff its not easy to find and is confusing I have bought many boards and 
found out they did not do what I hoped I have an update BBAI is supported that 
is very  good news the EVM is $600Be aware that BBAI rev A1 I think needs a mod 
for JTAG
Just to be clear I am not a linux expert so it appears all cores are supported 
and the Linux on Host ARM is SDK version it may night support all the bells 
Debian has for device drivers 
I have many years using DSP/BIOS and CCS and JTAG at board support level not 
Linux apps
Theres a lot of tools here and RTOS and dual cores isnt something you pick up 
over night
Pleny of good tutorials On learning TI RTOS using CCS and JTAG for a DSP 
application its really complex for a beginner and throw in MPUs and Cache and 
threads and 6 cores you really could spend a month learning tools alone
In all fairness a single core AM35X is simpler the beauty is TI has gel scripts 
to handle all cores and load code internally until MPU is set up for quick and 
simple apps on ARM and fast learning and low cost the Debian/Beagle approach is 
probally better its pretty obvious I am RTOS fan (-:
TI has world class tools and good documents
I cant help anyone that insists on mixing the Debian on ARM with TI RTOS on DSP 
I'm not qualified it may be possible
Looks like I was also wrong about omap l138 support for SDK the docs are 
confusing so maybe I buy a BBAI its cheaper than the EVM and play around I miss 
work I took care of mom 3 years she passed away October so I apologize at times 
Im grouchy
Hopefully I helped someone that feels good as well Im excited reading these 
docs so maybe I make a come back!!! and find some work
Regards
The SDK includes a real-time multitasking kernel, FAT file system, network 
communications support, examples, and drivers. The exact content of the SDK 
depends on the capabilities of the device, but all devices share common APIs 
and build on existing proven software components to ensure reliability and 
quality. The software components are fully tested to ensure that they work 
together with TI’s Code Composer Studio integrated development environment.

Supported Platforms


| Platform | Supported Devices | Supported EVMs |
| AM57x | AM5728, AM5726, AM5729, AM5718, AM5716, AM5708, AM5706, AM5748, 
AM5746, AM5749 | AM572x EVM (TMDSEVM572X),
AM572x Industrial Development Kit (TMDXIDK5728),
AM571x Industrial Development Kit (TMDXIDK5718),
AM574x Industrial Development Kit (TMDSIDK574),
AM5729 Industrial Development Kit (TMDSIDK572),
Beaglebone AI

 |


| 
| 
|  | 
BeagleBone® AI AM5729 development board for embedded Artificial Intellig...

What is BeagleBone® AI? Built on the proven 
BeagleBoard.org® open source Linux approach, Bea...
 |

 |

 |





On Monday, February 15, 2021, 11:52:18 AM CST, Jeff Andich 
 wrote:  
 
 Thanks Mark for providing us all this!  
I tried starting to port one of the main examples from TI RTOS SDK into the 
latest Beagleboard-X15 images this weekend. Built the IPC example under the 
link you posted yesterday.  Scp'd server_dsp1.xe66 to the SD card and then 
linked to it, and attempted to load.
It looks like it started to load but then complained that the resource table is 
not found.  I have lots more homework to do..
My plan dejour is to try to see how far I can get with that example on BB 
Debian and TI SDK Linux.
I do plan to develop the DSP application with CCS and JTAG, and deploy it using 
remoteproc from Linux once it's debugged.
Don't know if there are currently any Linux tools for debugging the other cores.
But at this point I'm not sure where this will all lead..
But it sounds like there's an appetite within the Beagle community to get this 
tested and working...  My guess is the more applications that can access the 
other processors on the SOC, the merrier for BB.org and TI..
On Mon, Feb 15, 2021, 12:34 PM Mark Lazarewicz  wrote:

 Looks like good examples here .I also saw M4 example on github.
 Dont see any documents on using Debian Linux and DSP Why? and wonder if that 
OS will supply tools to get the DSP executable transferred in correct 
formatCant even imagine debugging this with printf LOL and no jtagThe DSP has 
to be taken out of rest when  running linux


 Its documented here below why in the world someone would not use CCS and JTAG? 
and expect to run IPC on 6 core chip with no documents is beyond me. Any 
commercial customer would never accept being stonewalled by a vendor
Perhaps Debain/Beagle is for hobbyists only I  dont know 
And for Dimtry GCC is supported 

10.1. Target — Processor SDK RTOS Documentation


| 
| 
|  | 
10.1. Target — Processor SDK RTOS Documentation


 |

 |

 |






The following examples demonstrate some of the rudimentary IPC capabilities. 
They are mostly two processors examples. These examples may be built for any 
two processors on your device, but only for two at a time. An IPC Ping example 
using three processors is also presented at the end.


Why?



On Monday,

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-15 Thread Jeff Andich 
Thanks Mark for providing us all this!

I tried starting to port one of the main examples from TI RTOS SDK into the
latest Beagleboard-X15 images this weekend. Built the IPC example under the
link you posted yesterday.  Scp'd server_dsp1.xe66 to the SD card and then
linked to it, and attempted to load.

It looks like it started to load but then complained that the resource
table is not found.  I have lots more homework to do..

My plan dejour is to try to see how far I can get with that example on BB
Debian and TI SDK Linux.

I do plan to develop the DSP application with CCS and JTAG, and deploy it
using remoteproc from Linux once it's debugged.

Don't know if there are currently any Linux tools for debugging the other
cores.

But at this point I'm not sure where this will all lead..

But it sounds like there's an appetite within the Beagle community to get
this tested and working...  My guess is the more applications that can
access the other processors on the SOC, the merrier for BB.org and TI..

On Mon, Feb 15, 2021, 12:34 PM Mark Lazarewicz  wrote:

> Looks like good examples here .I also saw M4 example on github.
>
>  Dont see any documents on using Debian Linux and DSP Why?
> and wonder if that OS will supply tools to get the DSP executable
> transferred in correct format
> Cant even imagine debugging this with printf LOL and no jtag
> The DSP has to be taken out of rest when  running linux
>
>
>
>  Its documented here below why in the world someone would not use CCS and
> JTAG? and expect to run IPC on 6 core chip with no documents is beyond me.
> Any commercial customer would never accept being stonewalled by a vendor
>
> Perhaps Debain/Beagle is for hobbyists only I  dont know
>
> And for Dimtry GCC is supported
>
>
> 10.1. Target — Processor SDK RTOS Documentation
> 
>
> 10.1. Target — Processor SDK RTOS Documentation
>
>
> 
>
>
>
>
>
> The following examples demonstrate some of the rudimentary IPC
> capabilities. They are mostly two processors examples. These examples may
> be built for any two processors on your device, but only for two at a time.
> An IPC Ping example using three processors is also presented at the end.
>
>
> Why?
>
>
>
> On Monday, February 15, 2021, 09:41:20 AM CST, 'Mark Lazarewicz' via
> BeagleBoard  wrote:
>
>
> OpenVX,cmem,PRU and remote proc support today
>
>
> https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/index.html
>
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Tue, Feb 9, 2021 at 8:14 AM, jeff@gmail.com
>  wrote:
> I think I have a similar question in that I'm hoping to develop an
> application (as much of a software defined radio application as I can cram
> into this platform) which utilizes the C66 DSP's on the BB-X15.  I'm trying
> to converge on a process for developing a TI RTOS application for the C66's
> on the BB-X15 which is compatible with the BB Debian distro running on the
> A15's.  More on this later, hopefully.
>
> I imagine you've already stumbled upon the following, but it seems like a
> good starting point.
>
> https://e2e.ti.com/support/processors/f/791/t/765821.
>
> Also google all of the examples on of PRU applications .  My guess is that
> may also shed some light on how to develop and debug code for the other
> processors on the Sitara SOC of interest.
>
> I just received a USB100V2 JTAG cable, and I hope to start hacking on this
> on my BB-X15 in my spare time. I have a lot of questions on how this works,
> and I will post up when I think I have something worthwhile or relevant..
>
> Also, please post up as you make progress as I imagine there are others
> wanting guidance on developing applications on the other processors on the
> SOC and interfacing Linux to them.  There's not a lot of postings on the
> C66 or M4..
>
>
>
>
>
> On Wednesday, February 3, 2021 at 8:21:36 AM UTC-5 databac...@gmail.com
> wrote:
>
>
> Hi
> I and another student have been tasked with exploring ways to develop for
> the M4 processor using BBAI. We've had difficulty finding a good debug
> setup, preferably one where you could step through instructions in the M4
> processors.
>
> Could anyone point us towards whats worth looking in to?
>
> Regards, Fredrik Eriksson
>
> --
> 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/024abb86-4ada-4b24-b801-5119a941796en%40googlegroups.com
>

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-15 Thread 'Mark Lazarewicz' via BeagleBoard 
 Looks like good examples here .I also saw M4 example on github.
 Dont see any documents on using Debian Linux and DSP Why? and wonder if that 
OS will supply tools to get the DSP executable transferred in correct 
formatCant even imagine debugging this with printf LOL and no jtagThe DSP has 
to be taken out of rest when  running linux


 Its documented here below why in the world someone would not use CCS and JTAG? 
and expect to run IPC on 6 core chip with no documents is beyond me. Any 
commercial customer would never accept being stonewalled by a vendor
Perhaps Debain/Beagle is for hobbyists only I  dont know 
And for Dimtry GCC is supported 

10.1. Target — Processor SDK RTOS Documentation


| 
| 
|  | 
10.1. Target — Processor SDK RTOS Documentation


 |

 |

 |






The following examples demonstrate some of the rudimentary IPC capabilities. 
They are mostly two processors examples. These examples may be built for any 
two processors on your device, but only for two at a time. An IPC Ping example 
using three processors is also presented at the end.


Why?



On Monday, February 15, 2021, 09:41:20 AM CST, 'Mark Lazarewicz' via 
BeagleBoard  wrote:  
 
 OpenVX,cmem,PRU and remote proc support today
https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/index.html


Sent from Yahoo Mail on Android 
 
  On Tue, Feb 9, 2021 at 8:14 AM, jeff@gmail.com 
wrote:   I think I have a similar question in that I'm hoping to develop an 
application (as much of a software defined radio application as I can cram into 
this platform) which utilizes the C66 DSP's on the BB-X15.  I'm trying to 
converge on a process for developing a TI RTOS application for the C66's on the 
BB-X15 which is compatible with the BB Debian distro running on the A15's.  
More on this later, hopefully.  
I imagine you've already stumbled upon the following, but it seems like a good 
starting point.     
https://e2e.ti.com/support/processors/f/791/t/765821.
Also google all of the examples on of PRU applications .  My guess is that may 
also shed some light on how to develop and debug code for the other processors 
on the Sitara SOC of interest.  
I just received a USB100V2 JTAG cable, and I hope to start hacking on this on 
my BB-X15 in my spare time. I have a lot of questions on how this works, and I 
will post up when I think I have something worthwhile or relevant..  
Also, please post up as you make progress as I imagine there are others wanting 
guidance on developing applications on the other processors on the SOC and 
interfacing Linux to them.  There's not a lot of postings on the C66 or M4..




On Wednesday, February 3, 2021 at 8:21:36 AM UTC-5 databac...@gmail.com wrote:


HiI and another student have been tasked with exploring ways to develop for the 
M4 processor using BBAI. We've had difficulty finding a good debug setup, 
preferably one where you could step through instructions in the M4 processors. 

Could anyone point us towards whats worth looking in to? 

Regards, Fredrik Eriksson 



-- 
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/024abb86-4ada-4b24-b801-5119a941796en%40googlegroups.com.
  


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

Re: [beagleboard] Re: Debug tool for M4 processors in BBAI

2021-02-15 Thread 'Mark Lazarewicz' via BeagleBoard 
OpenVX,cmem,PRU and remote proc support today
https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/index.html


Sent from Yahoo Mail on Android 
 
  On Tue, Feb 9, 2021 at 8:14 AM, jeff@gmail.com 
wrote:   I think I have a similar question in that I'm hoping to develop an 
application (as much of a software defined radio application as I can cram into 
this platform) which utilizes the C66 DSP's on the BB-X15.  I'm trying to 
converge on a process for developing a TI RTOS application for the C66's on the 
BB-X15 which is compatible with the BB Debian distro running on the A15's.  
More on this later, hopefully.  
I imagine you've already stumbled upon the following, but it seems like a good 
starting point.     
https://e2e.ti.com/support/processors/f/791/t/765821.
Also google all of the examples on of PRU applications .  My guess is that may 
also shed some light on how to develop and debug code for the other processors 
on the Sitara SOC of interest.  
I just received a USB100V2 JTAG cable, and I hope to start hacking on this on 
my BB-X15 in my spare time. I have a lot of questions on how this works, and I 
will post up when I think I have something worthwhile or relevant..  
Also, please post up as you make progress as I imagine there are others wanting 
guidance on developing applications on the other processors on the SOC and 
interfacing Linux to them.  There's not a lot of postings on the C66 or M4..




On Wednesday, February 3, 2021 at 8:21:36 AM UTC-5 databac...@gmail.com wrote:


HiI and another student have been tasked with exploring ways to develop for the 
M4 processor using BBAI. We've had difficulty finding a good debug setup, 
preferably one where you could step through instructions in the M4 processors. 

Could anyone point us towards whats worth looking in to? 

Regards, Fredrik Eriksson 



-- 
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/024abb86-4ada-4b24-b801-5119a941796en%40googlegroups.com.
  

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