Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hi Mark, 

Thanks a lot for the response.
I think the idea in this processor SDK Linux tutorial 

 is 
to create Linux SD card from the Processor SDK Linux package, which 
somewhat echoes with your suggestion. 
I guess what confuses me is that in README.txt of the example, it just says 
"build firmware & userspace code" in the directory, which I assume both are 
done in BBB. Firmware is straightforward to build, because there is PRU 
code generation tools - compiler 
. I already used 
cross-compiler to build Userspace (ARM side) code. In the meantime, I just 
wonder if that can also be done in current BBB system. I will definitely 
study the document you suggest. Thanks!

In addition, the bigger problem is actually rpmsg_pru30 issue. That 
literally prevents me from running any rpmsg functions. As Dennis 
mentioned, this might be a device tree problem? I need to spend some time 
on this. 

Regards,
Cheng

在2021年4月30日星期五 UTC-4 下午9:06:24 写道：

> Cheng
>
> I'm actually using the SDK now so be careful about generic advise
> the instructions are for  Ubuntu not Debian
> 'Since I had questions myself right now  I realized this PRU code you have 
> just a small part of the SDK
> My point was you never read the SDK quick start
> Please do so here is the doc tarball
> '
> 12. Documentation Tarball — Processor SDK RTOS Documentation 
> 
>
> If you search the group on X15 and DSP Jeff Aused the SDK and ran the 
> binary on Debian(For the DSP with remore proc)
>
> So yes you can use Debian to load the PRU firmware you need a 
> corresponding ARM binary for that code. Jeff used the SDK to build that
>
> I dont know where you read to compile SDK examples on BBB its not 
> something I read
>
> So use Ubuntu box as instructions tell you too
>
> OR
>
> wait to see if Jeff Andlich can tell you if its feasable to attempt to 
> install the SDK on the board itself and compile the code  that doesn't 
> sound right to me
>
> OR
>
> create an account on E2E ask the people who designed the SDK especially if 
> your confused
>
> I can answer CCS JTAG barebone ARM questiion about SDK not interested in 
> Linux
>
> Please read the tarball in  the link
>
> Regard
> '
>
>
> On Friday, April 30, 2021, 03:09:09 PM CDT, Cheng Chen  
> wrote: 
>
>
> Hi all, 
>
> I am practicing PRU skills through some TI examples. I am playing with 
> PRU_ADC_onChip 
>
> example
>  
> and ran into a few questions. I wonder if you can help me with. 
>
> The nice thing about this example is it has a README.txt with all the 
> procedures. The idea is to use rpmsg to communicate between arm and pru 
> module and read out ADC value. 
> I am using a Beaglebone Black wireless.
> Here is the basic procedures.
>
> FILE STRUCTURE
> PRU_ADC
>   |
>   |--pru_adc_firmware.c firmware loaded into PRU0
>   |
>   |--pru_adc_userspace
>|--pru_adc_userspace.c userspace code that interacts with PRU0
>
> BUILD FIRMWARE & USERSPACE CODE
> $ cd /examples/am335x/PRU_ADC_onChip/
> $ make clean
> $ make
> $ cd pru_adc_userspace/
> $ make clean
> $ make
>
> My BBB wireless can compile pru code successfully because I installed 
> PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
> because ARM_CCT cross-compiler toochain environment is missing, in another 
> word, I need to install processor-sdk-am335x
>
> My first questions is can I install processor-sdk-am335x  into Debian 
> system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little 
> confused about the relationship between this SDK and Debian system. Why is 
> the tutorial asking me to compile  pru_adc_userspace.c  in the Beaglebone. 
> I thought it is supposed to be executed in a cross-compilation environment.
>
> I ended up installing processor-sdk-am335x on my linux desktop and 
> compiled successfully. Then I copied the generated file back to BBB 
> wireless. But when I tried to run the program, it shows the following 
> error. 
>
> Reading voltage at ADC Channel: 5
> /dev/rpmsg_pru30 could not be opened.
> Trying to initialize PRU using sysfs interface.
> ERROR: Could not open /dev/rpmsg_pru30
>
> Attached is the excerpt where the problem happened. Could anyone help me 
> with some hints of what is going on here? Much appreciated. 
>
>
> struct shared_struct message;
>
> /* use character device /dev/rpmsg_pru30 */
> char outputFilename[] = "/dev/rpmsg_pru30";
>
> /* test that /dev/rpmsg_pru30 exists */
> FILE *ofp;
> uint16_t returnedVoltage;
> ofp = fopen(outputFilename, "r");
>
> if (ofp == NULL) {
>
> printf("/dev/rpmsg_pru30 could not be opened. \n");
> printf("Trying to initialize PRU 

[beagleboard] Re: TI PRU_ADC_onChip example

[Cheng Chen]

Hey Dennis, 

Thanks for the reply. It makes a lot sense for cross-compiler. Thanks for 
the explanation. 
I am pretty sure I am running on 4.19.x-ti kernel. 
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo

I don't have any problem running other PRU examples. I also noticed that 
the original firmware is not running at first. But once it is loaded, it 
seems ok. I tried creating /dev/rpmsg by using "echo hello > 
/dev/rpmsg_pru30" before running example code. But it would leads to 
program freeze. I am also exploring direct memory access method to save 
acquired values in shared memory, but I haven't got any results yet. 

I think I will investigate into the device tree issue as you suggested. 
Thanks!

Regards,
Cheng

在2021年4月30日星期五 UTC-4 下午8:45:57 写道：

> On Fri, 30 Apr 2021 13:09:02 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Cheng Chen
>  wrote:
>
>
> >My BBB wireless can compile pru code successfully because I installed 
> >PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
> >because ARM_CCT cross-compiler toochain environment is missing, in 
> another 
> >word, I need to install processor-sdk-am335x
> >
> The key is probably in the phrase "cross-compiler"... If you are
> compiling ON the Beagle, you are using the "native" compiler, not a
> cross-compiler ("cross" implies a toolchain that runs on a different
> OS/architecture but which builds binary files meant for the target of the
> toolchain -- but you are ON ARM, building FOR ARM).
>
> >My first questions is can I install processor-sdk-am335x into Debian 
> >system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a 
> little 
> >confused about the relationship between this SDK and Debian system. Why 
> is 
> >the tutorial asking me to compile pru_adc_userspace.c in the Beaglebone. 
> >I thought it is supposed to be executed in a cross-compilation 
> environment.
> >
>
> Cross compilation is used mostly for a couple of reasons: either the
> target system does not support a native compiler (you aren't going to run a
> compiler on something like a Tiva C board, or an Arduino Due [both of which
> run ARM M-series processors] -- though the native compiler on a
> Beagle/Debian might be able to build files that can be downloaded to such
> boards); the target board is not yet built -- in which case one is likely
> going to be "running" the code using something like QEMU or other software
> emulation of the hardware system; the target board has a compiler, but the
> speed of the cross-compiler environment is much faster (consider a
> hyper-threaded 64-bit processor -- which is seen as 8-cores by the OS, each
> running at 2.5-3.5GHz, with 12GB of RAM, vs a single 32-bit core running at
> 1GB with less than 1GB of RAM).
>
> >I ended up installing processor-sdk-am335x on my linux desktop and 
> compiled 
> >successfully. Then I copied the generated file back to BBB wireless. But 
> >when I tried to run the program, it shows the following error. 
> >
> >Reading voltage at ADC Channel: 5
> >/dev/rpmsg_pru30 could not be opened.
> >Trying to initialize PRU using sysfs interface.
> >ERROR: Could not open /dev/rpmsg_pru30
> >
>
> This is a different matter, and likely means the device tree
> configuration is not set correctly -- over the last few years there have
> been two INCOMPATIBLE means of accessing the PRU. RemoteProc/RPMsg is the
> newer system, pru_uio is older -- current images for the Beagle load
> RemoteProc -- check /boot/uEnv.txt to see what version your system is
> loading...
>
> ###PRUSS OPTIONS
> ###pru_rproc (4.14.x-ti kernel)
> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
> ###pru_rproc (4.19.x-ti kernel)
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
> ###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
> ###
>
> ... however, I don't seem to have any /dev/rpmsg* entries either.
>
> I'm sure this have been brought up in this forum a few times in the
> last year or so, but I don't recall the solution (if any). I did find that
> the default firmware was not "running"... But starting it didn't add the
> /dev/rpmsg*
>
> debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/*
> cat: /sys/class/remoteproc/remoteproc1/device: Is a directory
> am335x-pru0-fw
> 4a334000.pru
> cat: /sys/class/remoteproc/remoteproc1/power: Is a directory
> offline <*
> cat: /sys/class/remoteproc/remoteproc1/subsystem: Is a directory
> DEVTYPE=remoteproc
> debian@beaglebone:~$ echo 'start' > /sys/class/remoteproc/remoteproc1/state
> debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/*
> cat: /sys/class/remoteproc/remoteproc1/device: Is a directory
> am335x-pru0-fw
> 4a334000.pru
> cat: /sys/class/remoteproc/remoteproc1/power: Is a directory
> running <*
> cat: /sys/class/remoteproc/remoteproc1/subsystem: Is 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 Cheng
I'm actually using the SDK now so be careful about generic advisethe 
instructions are for  Ubuntu not Debian'Since I had questions myself right now  
I realized this PRU code you have just a small part of the SDKMy point was you 
never read the SDK quick startPlease do so here is the doc tarball'12. 
Documentation Tarball — Processor SDK RTOS Documentation

If you search the group on X15 and DSP Jeff Aused the SDK and ran the binary on 
Debian(For the DSP with remore proc)
So yes you can use Debian to load the PRU firmware you need a corresponding ARM 
binary for that code. Jeff used the SDK to build that
I dont know where you read to compile SDK examples on BBB its not something I 
read
So use Ubuntu box as instructions tell you too
OR
wait to see if Jeff Andlich can tell you if its feasable to attempt to install 
the SDK on the board itself and compile the code  that doesn't sound right to me
OR
create an account on E2E ask the people who designed the SDK especially if your 
confused
I can answer CCS JTAG barebone ARM questiion about SDK not interested in Linux
Please read the tarball in  the link
Regard'

On Friday, April 30, 2021, 03:09:09 PM CDT, Cheng Chen 
 wrote:  
 
 Hi all, 
I am practicing PRU skills through some TI examples. I am playing with 
PRU_ADC_onChip example and ran into a few questions. I wonder if you can help 
me with. 
The nice thing about this example is it has a README.txt with all the 
procedures. The idea is to use rpmsg to communicate between arm and pru module 
and read out ADC value. I am using a Beaglebone Black wireless.Here is the 
basic procedures.
FILE STRUCTUREPRU_ADC  |  |--pru_adc_firmware.c firmware loaded into PRU0  |  
|--pru_adc_userspace       |--pru_adc_userspace.c userspace code that interacts 
with PRU0
BUILD FIRMWARE & USERSPACE CODE$ cd 
/examples/am335x/PRU_ADC_onChip/$ make clean$ 
make$ cd pru_adc_userspace/$ make clean$ make
My BBB wireless can compile pru code successfully because I installed PRU_CGT 
compiler. But it is unable to compile ARM code. I think that is because ARM_CCT 
cross-compiler toochain environment is missing, in another word, I need to 
install processor-sdk-am335x
My first questions is can I install processor-sdk-am335x  into Debian system I 
currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused 
about the relationship between this SDK and Debian system. Why is the tutorial 
asking me to compile pru_adc_userspace.c  in the Beaglebone. I thought it is 
supposed to be executed in a cross-compilation environment.
I ended up installing processor-sdk-am335x on my linux desktop and compiled 
successfully. Then I copied the generated file back to BBB wireless. But when I 
tried to run the program, it shows the following error. 
Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to 
initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30
Attached is the excerpt where the problem happened. Could anyone help me with 
some hints of what is going on here? Much appreciated. 

struct shared_struct message;
 /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = 
"/dev/rpmsg_pru30";
 /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; 
ofp = fopen(outputFilename, "r");
 if (ofp == NULL) {
 printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to 
initialize PRU using sysfs interface.\n");
 FILE *sysfs_node; char firmware[] = 
"/sys/class/remoteproc/remoteproc1/firmware"; char firmwareName[] = 
"PRU_ADC_onChip.out"; sysfs_node = fopen(firmware, "r+"); if (sysfs_node == 
NULL) { printf("cannot open firmware sysfs_node"); return EXIT_FAILURE; } 
fwrite(, sizeof(uint8_t), sizeof(firmwareName), sysfs_node); 
fclose(sysfs_node);
 char pruState[] = "/sys/class/remoteproc/remoteproc1/state"; char start[] = 
"start"; sysfs_node = fopen(pruState, "r+"); if (sysfs_node == NULL) { 
printf("cannot open state sysfs_node"); return EXIT_FAILURE; } fwrite(, 
sizeof(uint8_t), sizeof(start), sysfs_node); fclose(sysfs_node);
 /* give RPMSG time to initialize */ sleep(3);
 ofp = fopen(outputFilename, "r");
 if (ofp == NULL) { printf("ERROR: Could not open /dev/rpmsg_pru30\n"); 
exit(EXIT_FAILURE); } }






-- 
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/1d43aa7b-0e94-4431-9e31-13545213940bn%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 

Re: [beagleboard] TI PRU_ADC_onChip example

[Cheng Chen]

Hey Mark, 

Thanks for spending time for replying. I really appreciate it. 
I totally agree with you that one should spend time investigating first. I 
apologize if they are dumb questions, but I have stuck there for two weeks. 
I am more a circuit guy and just started picking up Beaglebone as a hobby 
and potential career expansion. 

My first intention is to post in TI E2E support forums , 
but it requires a company email to do so. If this particular .org is not a 
good place for rookie questions, would you please advise some place for 
suitable for discussion?

Regarding to the documents, are you referring to processor SDK Linux 
Software Developer's guide? If that is the one, I did follow its 
instructions, but maybe I missed something. I will go over it again. If 
that's not the one, which document are you referring to? I also went 
through PRUcookbook and Exploring BeagleBone by Derek Molly. Not a lot are 
mentioned regarding this topic. 

The code is built-in in the Beaglebone Black, this is one of the reasons I 
am confused why it cannot be compiled. One can also download freely from TI 
github 
(https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/).
 

Again thanks for the advice and suggestion. I am very glad that there is 
such a nice place that I can call for help and I hope after some practice I 
am also able to contribute here. 

Regards,
Cheng

在2021年4月30日星期五 UTC-4 下午5:09:01 写道：

> Hello 
>
> I know the code. It's all explained in the SDK documention. I also like 
> these examples.
> Your asking questions about an SDK that's supported by Texas Instruments. 
> You do understand this .org group you posted in may contain TI employees 
> but is NOT TI support it's Beagle board Debian.
>
>  I think if you read the documents you will understand the answers
>
>  I'm sure you could compile this with some work the sdk instructions talk 
> about This. 
>
> Hypothetical question ❓
> If the instructions told you a virtual box build was not supported and not 
> recommended would you use one anyway and then ask the person who told you 
> not too do this why it doesn't work.
>
> I'm struggling to be nice in this reply.
>
>  I remember asking questions as a young engineer that clearly showed I 
> made zero effort to research anything.
>
> Then one day I got some really critical replies about my skills.
>
> Do some reading then if stuck ask questions
>
> Or better yet follow what the sdk instructions suggest.
>
> If you found this code  on internet and don't have a TI account or are not 
> eligible for ITAR restrictions to download the sdk  you have a big problem.
>
> I see you have a Gmail account
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen
>  wrote:
>
> Hi all, 
>
> I am practicing PRU skills through some TI examples. I am playing with 
> PRU_ADC_onChip 
>
> example
>  
> and ran into a few questions. I wonder if you can help me with. 
>
> The nice thing about this example is it has a README.txt with all the 
> procedures. The idea is to use rpmsg to communicate between arm and pru 
> module and read out ADC value. 
> I am using a Beaglebone Black wireless.
> Here is the basic procedures.
>
> FILE STRUCTURE
> PRU_ADC
>   |
>   |--pru_adc_firmware.c firmware loaded into PRU0
>   |
>   |--pru_adc_userspace
>|--pru_adc_userspace.c userspace code that interacts with PRU0
>
> BUILD FIRMWARE & USERSPACE CODE
> $ cd /examples/am335x/PRU_ADC_onChip/
> $ make clean
> $ make
> $ cd pru_adc_userspace/
> $ make clean
> $ make
>
> My BBB wireless can compile pru code successfully because I installed 
> PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
> because ARM_CCT cross-compiler toochain environment is missing, in another 
> word, I need to install processor-sdk-am335x
>
> My first questions is can I install processor-sdk-am335x  into Debian 
> system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little 
> confused about the relationship between this SDK and Debian system. Why is 
> the tutorial asking me to compile  pru_adc_userspace.c  in the Beaglebone. 
> I thought it is supposed to be executed in a cross-compilation environment.
>
> I ended up installing processor-sdk-am335x on my linux desktop and 
> compiled successfully. Then I copied the generated file back to BBB 
> wireless. But when I tried to run the program, it shows the following 
> error. 
>
> Reading voltage at ADC Channel: 5
> /dev/rpmsg_pru30 could not be opened.
> Trying to initialize PRU using sysfs interface.
> ERROR: Could not open /dev/rpmsg_pru30
>
> Attached is the excerpt where the problem happened. Could 

[beagleboard] Re: TI PRU_ADC_onChip example

[Dennis Lee Bieber]

On Fri, 30 Apr 2021 13:09:02 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Cheng Chen
 wrote:


>My BBB wireless can compile pru code successfully because I installed 
>PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
>because ARM_CCT cross-compiler toochain environment is missing, in another 
>word, I need to install processor-sdk-am335x
>
The key is probably in the phrase "cross-compiler"... If you are
compiling ON the Beagle, you are using the "native" compiler, not a
cross-compiler ("cross" implies a toolchain that runs on a different
OS/architecture but which builds binary files meant for the target of the
toolchain -- but you are ON ARM, building FOR ARM).

>My first questions is can I install processor-sdk-am335x  into Debian 
>system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little 
>confused about the relationship between this SDK and Debian system. Why is 
>the tutorial asking me to compile  pru_adc_userspace.c  in the Beaglebone. 
>I thought it is supposed to be executed in a cross-compilation environment.
>

Cross compilation is used mostly for a couple of reasons: either the
target system does not support a native compiler (you aren't going to run a
compiler on something like a Tiva C board, or an Arduino Due [both of which
run ARM M-series processors] -- though the native compiler on a
Beagle/Debian might be able to build files that can be downloaded to such
boards); the target board is not yet built -- in which case one is likely
going to be "running" the code using something like QEMU or other software
emulation of the hardware system; the target board has a compiler, but the
speed of the cross-compiler environment is much faster (consider a
hyper-threaded 64-bit processor -- which is seen as 8-cores by the OS, each
running at 2.5-3.5GHz, with 12GB of RAM, vs a single 32-bit core running at
1GB with less than 1GB of RAM).

>I ended up installing processor-sdk-am335x on my linux desktop and compiled 
>successfully. Then I copied the generated file back to BBB wireless. But 
>when I tried to run the program, it shows the following error. 
>
>Reading voltage at ADC Channel: 5
>/dev/rpmsg_pru30 could not be opened.
>Trying to initialize PRU using sysfs interface.
>ERROR: Could not open /dev/rpmsg_pru30
>

This is a different matter, and likely means the device tree
configuration is not set correctly -- over the last few years there have
been two INCOMPATIBLE means of accessing the PRU. RemoteProc/RPMsg is the
newer system, pru_uio is older -- current images for the Beagle load
RemoteProc -- check /boot/uEnv.txt to see what version your system is
loading...

###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###

... however, I don't seem to have any /dev/rpmsg* entries either.

I'm sure this have been brought up in this forum a few times in the
last year or so, but I don't recall the solution (if any). I did find that
the default firmware was not "running"...  But starting it didn't add the
/dev/rpmsg*

debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/*
cat: /sys/class/remoteproc/remoteproc1/device: Is a directory
am335x-pru0-fw
4a334000.pru
cat: /sys/class/remoteproc/remoteproc1/power: Is a directory
offline <*
cat: /sys/class/remoteproc/remoteproc1/subsystem: Is a directory
DEVTYPE=remoteproc
debian@beaglebone:~$ echo 'start' > /sys/class/remoteproc/remoteproc1/state
debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/*
cat: /sys/class/remoteproc/remoteproc1/device: Is a directory
am335x-pru0-fw
4a334000.pru
cat: /sys/class/remoteproc/remoteproc1/power: Is a directory
running <*
cat: /sys/class/remoteproc/remoteproc1/subsystem: Is a directory
DEVTYPE=remoteproc



-- 
Dennis L Bieber

-- 
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/7t3p8gpavcmimaf0mo826i5ak6sr8l6qg6%404ax.com.

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

Hello 
I know the code. It's all explained in the SDK documention. I also like these 
examples.Your asking questions about an SDK that's supported by Texas 
Instruments. You do understand this .org group you posted in may contain TI 
employees but is NOT TI support it's Beagle board Debian.
 I think if you read the documents you will understand the answers
 I'm sure you could compile this with some work the sdk instructions talk about 
This. 
Hypothetical question ❓If the instructions told you a virtual box build was not 
supported and not recommended would you use one anyway and then ask the person 
who told you not too do this why it doesn't work.
I'm struggling to be nice in this reply.
 I remember asking questions as a young engineer that clearly showed I made 
zero effort to research anything.
Then one day I got some really critical replies about my skills.
Do some reading then if stuck ask questions
Or better yet follow what the sdk instructions suggest.
If you found this code  on internet and don't have a TI account or are not 
eligible for ITAR restrictions to download the sdk  you have a big problem.
I see you have a Gmail account





Sent from Yahoo Mail on Android 
 
  On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen wrote:   Hi 
all, 
I am practicing PRU skills through some TI examples. I am playing with 
PRU_ADC_onChip example and ran into a few questions. I wonder if you can help 
me with. 
The nice thing about this example is it has a README.txt with all the 
procedures. The idea is to use rpmsg to communicate between arm and pru module 
and read out ADC value. I am using a Beaglebone Black wireless.Here is the 
basic procedures.
FILE STRUCTUREPRU_ADC  |  |--pru_adc_firmware.c firmware loaded into PRU0  |  
|--pru_adc_userspace       |--pru_adc_userspace.c userspace code that interacts 
with PRU0
BUILD FIRMWARE & USERSPACE CODE$ cd 
/examples/am335x/PRU_ADC_onChip/$ make clean$ 
make$ cd pru_adc_userspace/$ make clean$ make
My BBB wireless can compile pru code successfully because I installed PRU_CGT 
compiler. But it is unable to compile ARM code. I think that is because ARM_CCT 
cross-compiler toochain environment is missing, in another word, I need to 
install processor-sdk-am335x
My first questions is can I install processor-sdk-am335x  into Debian system I 
currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused 
about the relationship between this SDK and Debian system. Why is the tutorial 
asking me to compile pru_adc_userspace.c  in the Beaglebone. I thought it is 
supposed to be executed in a cross-compilation environment.
I ended up installing processor-sdk-am335x on my linux desktop and compiled 
successfully. Then I copied the generated file back to BBB wireless. But when I 
tried to run the program, it shows the following error. 
Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to 
initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30
Attached is the excerpt where the problem happened. Could anyone help me with 
some hints of what is going on here? Much appreciated. 

struct shared_struct message;
 /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = 
"/dev/rpmsg_pru30";
 /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; 
ofp = fopen(outputFilename, "r");
 if (ofp == NULL) {
 printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to 
initialize PRU using sysfs interface.\n");
 FILE *sysfs_node; char firmware[] = 
"/sys/class/remoteproc/remoteproc1/firmware"; char firmwareName[] = 
"PRU_ADC_onChip.out"; sysfs_node = fopen(firmware, "r+"); if (sysfs_node == 
NULL) { printf("cannot open firmware sysfs_node"); return EXIT_FAILURE; } 
fwrite(, sizeof(uint8_t), sizeof(firmwareName), sysfs_node); 
fclose(sysfs_node);
 char pruState[] = "/sys/class/remoteproc/remoteproc1/state"; char start[] = 
"start"; sysfs_node = fopen(pruState, "r+"); if (sysfs_node == NULL) { 
printf("cannot open state sysfs_node"); return EXIT_FAILURE; } fwrite(, 
sizeof(uint8_t), sizeof(start), sysfs_node); fclose(sysfs_node);
 /* give RPMSG time to initialize */ sleep(3);
 ofp = fopen(outputFilename, "r");
 if (ofp == NULL) { printf("ERROR: Could not open /dev/rpmsg_pru30\n"); 
exit(EXIT_FAILURE); } }






-- 
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/1d43aa7b-0e94-4431-9e31-13545213940bn%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] TI PRU_ADC_onChip example

[Cheng Chen]

Hi all, 

I am practicing PRU skills through some TI examples. I am playing with 
PRU_ADC_onChip 
example
 
and ran into a few questions. I wonder if you can help me with. 

The nice thing about this example is it has a README.txt with all the 
procedures. The idea is to use rpmsg to communicate between arm and pru 
module and read out ADC value. 
I am using a Beaglebone Black wireless.
Here is the basic procedures.

FILE STRUCTURE
PRU_ADC
  |
  |--pru_adc_firmware.c firmware loaded into PRU0
  |
  |--pru_adc_userspace
   |--pru_adc_userspace.c userspace code that interacts with PRU0

BUILD FIRMWARE & USERSPACE CODE
$ cd /examples/am335x/PRU_ADC_onChip/
$ make clean
$ make
$ cd pru_adc_userspace/
$ make clean
$ make

My BBB wireless can compile pru code successfully because I installed 
PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
because ARM_CCT cross-compiler toochain environment is missing, in another 
word, I need to install processor-sdk-am335x

My first questions is can I install processor-sdk-am335x  into Debian 
system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little 
confused about the relationship between this SDK and Debian system. Why is 
the tutorial asking me to compile  pru_adc_userspace.c  in the Beaglebone. 
I thought it is supposed to be executed in a cross-compilation environment.

I ended up installing processor-sdk-am335x on my linux desktop and compiled 
successfully. Then I copied the generated file back to BBB wireless. But 
when I tried to run the program, it shows the following error. 

Reading voltage at ADC Channel: 5
/dev/rpmsg_pru30 could not be opened.
Trying to initialize PRU using sysfs interface.
ERROR: Could not open /dev/rpmsg_pru30

Attached is the excerpt where the problem happened. Could anyone help me 
with some hints of what is going on here? Much appreciated. 


struct shared_struct message;

/* use character device /dev/rpmsg_pru30 */
char outputFilename[] = "/dev/rpmsg_pru30";

/* test that /dev/rpmsg_pru30 exists */
FILE *ofp;
uint16_t returnedVoltage;
ofp = fopen(outputFilename, "r");

if (ofp == NULL) {

printf("/dev/rpmsg_pru30 could not be opened. \n");
printf("Trying to initialize PRU using sysfs interface.\n");

FILE *sysfs_node;
char firmware[] = "/sys/class/remoteproc/remoteproc1/firmware";
char firmwareName[] = "PRU_ADC_onChip.out";
sysfs_node = fopen(firmware, "r+");
if (sysfs_node == NULL) {
printf("cannot open firmware sysfs_node");
return EXIT_FAILURE;
}
fwrite(, sizeof(uint8_t), sizeof(firmwareName),
sysfs_node);
fclose(sysfs_node);

char pruState[] = "/sys/class/remoteproc/remoteproc1/state";
char start[] = "start";
sysfs_node = fopen(pruState, "r+");
if (sysfs_node == NULL) {
printf("cannot open state sysfs_node");
return EXIT_FAILURE;
}
fwrite(, sizeof(uint8_t), sizeof(start), sysfs_node);
fclose(sysfs_node);

/* give RPMSG time to initialize */
sleep(3);

ofp = fopen(outputFilename, "r");

if (ofp == NULL) {
printf("ERROR: Could not open /dev/rpmsg_pru30\n");
exit(EXIT_FAILURE);
}
}





-- 
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/1d43aa7b-0e94-4431-9e31-13545213940bn%40googlegroups.com.

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Dennis Lee Bieber]

On Fri, 30 Apr 2021 08:22:10 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>I checked with ls -ls /dev/mem logged in as debian and it's there.
>
debian@beaglebone:~$ ls -ls /dev/mem
0 crw-r- 1 root kmem 1, 1 Apr 30 12:06 /dev/mem
debian@beaglebone:~$
debian@beaglebone:~$ groups
debian adm kmem dialout cdrom floppy audio dip video plugdev users
systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide
xenomai weston-launch tisdk docker iio spi admin gpio
debian@beaglebone:~$


That is what my BBB shows.

Owner (root) has R/W permission
Group (kmem) has Read-Only permission.

The debian account has kmem group access.

From your earlier post...

>fd = open ("/dev/mem", O_RDWR | O_SYNC);

... you are asking for R/W access -- which is not set for members of the
kmem group. What happens if you attempt to open /dev/mem for read-only
access?


-- 
Dennis L Bieber

-- 
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/33bo8g5lcseq60uiq86ubie7pspjaioidm%404ax.com.

Re: [beagleboard] versioning beaglebone images with OSTree

[John Allwine]

Thanks Robert! Do you have a sense of what the major hurdles of 
implementing this are? From what I can tell:

* Setting up U-Boot to look in the proper ostree deployment
* Setting up bind mounts to the directories in /
* Ensuring the system doesn't write to any directories other than /etc and 
/var
* Handling merges of /etc on update
* Some kind of automatic rollback handling in case something goes wrong 
with an update and system won't boot

Does this sound right? Any thoughts on any of those? Am I missing anything 
major (my guess is likely!)?

On Thursday, April 22, 2021 at 9:35:57 AM UTC-6 RobertCNelson wrote:

> On Fri, Apr 16, 2021 at 7:04 PM Robert Nelson  wrote:
> >
> > On Fri, Apr 16, 2021 at 4:19 PM John Allwine  wrote:
> > >
> > > I'd like to start a discussion about creating complete Beaglebone 
> images that leverage OSTree to be able to atomically update the system as a 
> whole. The scripts in https://github.com/beagleboard/image-builder 
> generate complete images for the Beaglebone that include specific kernel, 
> apt packages, boot settings, git repositories, etc. Updating a deployed 
> Beaglebone without reflashing a new image involves piecemeal updating of 
> those various components. Improperly updating can leave the system in a 
> broken state and can be difficult to get back into a good state. It would 
> be great to be able to leverage those image-builder scripts to construct 
> the rootfs, add that tree as a commit to an OSTree repository and properly 
> configured Beaglebones could download that commit and atomically switch to 
> it to update the whole system while preserving portions of the system such 
> as home directories and other key directories (/etc, /var?). If something 
> did break, rolling back is easy as well.
> > >
> > > Configuring a Beaglebone this way would make most of the system 
> read-only so using apt-get to install new packages wouldn't work without 
> altering its implementation, but that seems like a worthy trade off. This 
> would be for someone who has a Beaglebone with an out-of-the-box image and 
> some scripts/servers set up in their home directory who doesn't want to 
> worry too much about the system as a whole, but wants to be able to easily 
> update it without reflashing or doing piecemeal updates. People who develop 
> software for Beaglebones in their customers' devices could host their own 
> OSTree repository and make their own modifications to the image-builder 
> scripts if they have their own set of system dependencies (this is what I'd 
> like to do).
> > >
> > > Does anyone else think this would be useful? Is there anyone with the 
> expertise to know what details would need to be taken into account to make 
> this work properly?
> > >
> > > OSTree documentation is here: https://ostreedev.github.io/ostree/
> > > It lists a number of examples of it being used in various Linux 
> distributions.
> >
> > I remember seeing one of Peter Robinson's demo of Fedora IoT a few
> > years back at ELC, that used OSTree+btrfs. It worked pretty well. At
> > that time, I made sure btrfs worked well for us, to possibly look down
> > that road. My biggest issue, the 4gb eMMC, was too limited for the
> > out of box images to do something like that. For an iot/console image
> > the idea would still work well.. While working on bullseye images
> > this week, i noticed we still have the "--no-merged-usr" flag for
> > debootstrap, we should try with that removed in 'bullseye', as ostree
> > needs that..
> >
> > We did have ostree installed on the lxqt images:
> >
> > 
> https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138
> >
> > --no-merged-usr (due to bugs in stretch/buster..)
> > 
> https://github.com/beagleboard/image-builder/blob/master/scripts/debootstrap.sh#L138
>
> bullseye and later now has --no-merged-usr disabled:
>
>
> https://github.com/RobertCNelson/omap-image-builder/commit/2d7bf137e3447038142a83751ed4fca76faca5fe
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

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

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Walter Cromer]

Mark ,

pwm4.pru0.c compiles fine from a command line in PUTTY using make 
TARGET=pwm4.pru0

When I try to run pwm_test.c within the cloud9 IDE I get this message from 
the program.  

Compiling /var/lib/cloud9/PRUCookbook/docs/05blocks/code/pwm-test.c ...
/var/lib/cloud9/common/Makefile:28: 
MODEL=TI_AM335x_BeagleBone_Black_Wireless,TARGET=,COMMON=/var/lib/cloud9/common
make: 'pwm-test' is up to date.
Servo tester
ERROR: could not open /dev/mem.

I checked with ls -ls /dev/mem logged in as debian and it's there.

Any ideas?




On Friday, April 30, 2021 at 10:06:42 AM UTC-4 Walter Cromer wrote:

> Well, yes indeed, it is there this morning.  I'll retry the code later and 
> get back to you.
>
>
> On Thursday, April 29, 2021 at 4:04:42 PM UTC-4 Mark A. Yoder wrote:
>
>> Are you sure /dev/mem isn't there?  I think it's required.
>>
>> bone$ *ls -ls /dev/mem*
>> 0 crw-r- 1 root kmem 1, 1 Apr 14 09:11 /dev/mem
>> bone$ *groups*
>> debian adm *kmem* dialout cdrom floppy audio dip video plugdev users 
>> systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide 
>> xenomai weston-launch tisdk docker iio spi admin gpio
>>
>> You should be in the kmem group by default so sudo isn't needed.
>>
>> --Mark
>>
>> On Thursday, April 29, 2021 at 3:17:16 PM UTC-4 
>> wal...@edenconceptsllc.com wrote:
>>
>>> Here's the code too.   Sorry, should have included it.
>>>
>>> int fd;
>>> printf("Setting up pru0 memory access.\n");
>>>
>>> fd = open ("/dev/mem", O_RDWR | O_SYNC);
>>> if (fd == -1) {
>>> printf ("ERROR: could not open /dev/mem.\n\n");
>>> return 1;
>>> }
>>>
>>>
>>> When I look for /dev/mem it doesn't exist whether logged in as debian or 
>>> root
>>>
>>>
>>>
>>> On Thursday, April 29, 2021 at 3:15:10 PM UTC-4 Walter Cromer wrote:
>>>
 Mark - I'm integrating the concepts from the PRUCookbook so I can send 
 some control parameters entered by the user in the host side program and 
 pass them over to the PRU0 firmware.

 I'm getting this error when I try to compile the code.

 Setting up pru0 memory access.
 ERROR: could not open /dev/mem.

 Any ideas?

 I'm running a BBB Wireless with video and audio disabled.

 Here's the output of version.sh

 debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
 [sudo] password for debian:
 git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
 eeprom:[A335BNLTBWA52027BBWG0227]
 model:[TI_AM335x_BeagleBone_Black_Wireless]
 dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
 bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
 2019.04-2-g07d5700e21]:[location: dd MBR]
 bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
 2018.03-2-gac9cce7c6a]:[location: dd MBR]
 UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
 UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
 UBOOT: Loaded Overlay:[BB-ADC-00A0]
 UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
 UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
 UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
 UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
 kernel:[4.19.94-ti-r61]
 nodejs:[v10.15.2]
 /boot/uEnv.txt Settings:
 uboot_overlay_options:[enable_uboot_overlays=1]

 uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
 uboot_overlay_options:[disable_uboot_overlay_video=1]
 uboot_overlay_options:[disable_uboot_overlay_audio=1]

 uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
 uboot_overlay_options:[enable_uboot_cape_universal=1]

 uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
 pkg check: to individually upgrade run: [sudo apt install 
 --only-upgrade ]
 pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
 pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
 pkg:[kmod]:[26-1]
 pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
 pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
 groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
 plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep 
 remoteproc 
 admin spi iio docker tisdk weston-launch xenomai cloud9ide]
 cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
 net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
 dmesg | grep remote
 [   69.927418] remoteproc remoteproc0: wkup_m3 is available
 [   70.105672] remoteproc remoteproc0: powering up wkup_m3
 [   70.105706] remoteproc remoteproc0: Booting fw image 
 am335x-pm-firmware.elf, size 217148
 [   70.106000] remoteproc remoteproc0: remote processor wkup_m3 is now 
 up
 [   72.319951] remoteproc remoteproc1: 

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Walter Cromer]

Well, yes indeed, it is there this morning.  I'll retry the code later and 
get back to you.


On Thursday, April 29, 2021 at 4:04:42 PM UTC-4 Mark A. Yoder wrote:

> Are you sure /dev/mem isn't there?  I think it's required.
>
> bone$ *ls -ls /dev/mem*
> 0 crw-r- 1 root kmem 1, 1 Apr 14 09:11 /dev/mem
> bone$ *groups*
> debian adm *kmem* dialout cdrom floppy audio dip video plugdev users 
> systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide 
> xenomai weston-launch tisdk docker iio spi admin gpio
>
> You should be in the kmem group by default so sudo isn't needed.
>
> --Mark
>
> On Thursday, April 29, 2021 at 3:17:16 PM UTC-4 wal...@edenconceptsllc.com 
> wrote:
>
>> Here's the code too.   Sorry, should have included it.
>>
>> int fd;
>> printf("Setting up pru0 memory access.\n");
>>
>> fd = open ("/dev/mem", O_RDWR | O_SYNC);
>> if (fd == -1) {
>> printf ("ERROR: could not open /dev/mem.\n\n");
>> return 1;
>> }
>>
>>
>> When I look for /dev/mem it doesn't exist whether logged in as debian or 
>> root
>>
>>
>>
>> On Thursday, April 29, 2021 at 3:15:10 PM UTC-4 Walter Cromer wrote:
>>
>>> Mark - I'm integrating the concepts from the PRUCookbook so I can send 
>>> some control parameters entered by the user in the host side program and 
>>> pass them over to the PRU0 firmware.
>>>
>>> I'm getting this error when I try to compile the code.
>>>
>>> Setting up pru0 memory access.
>>> ERROR: could not open /dev/mem.
>>>
>>> Any ideas?
>>>
>>> I'm running a BBB Wireless with video and audio disabled.
>>>
>>> Here's the output of version.sh
>>>
>>> debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
>>> [sudo] password for debian:
>>> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
>>> eeprom:[A335BNLTBWA52027BBWG0227]
>>> model:[TI_AM335x_BeagleBone_Black_Wireless]
>>> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
>>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>> 2019.04-2-g07d5700e21]:[location: dd MBR]
>>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>>> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
>>> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
>>> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
>>> UBOOT: Loaded Overlay:[BB-ADC-00A0]
>>> UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
>>> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
>>> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
>>> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
>>> kernel:[4.19.94-ti-r61]
>>> nodejs:[v10.15.2]
>>> /boot/uEnv.txt Settings:
>>> uboot_overlay_options:[enable_uboot_overlays=1]
>>>
>>> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
>>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>>>
>>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
>>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>>> uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
>>> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
>>> ]
>>> pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
>>> pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
>>> pkg:[kmod]:[26-1]
>>> pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
>>> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
>>> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>>> plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
>>> admin spi iio docker tisdk weston-launch xenomai cloud9ide]
>>> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>>> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
>>> dmesg | grep remote
>>> [   69.927418] remoteproc remoteproc0: wkup_m3 is available
>>> [   70.105672] remoteproc remoteproc0: powering up wkup_m3
>>> [   70.105706] remoteproc remoteproc0: Booting fw image 
>>> am335x-pm-firmware.elf, size 217148
>>> [   70.106000] remoteproc remoteproc0: remote processor wkup_m3 is now up
>>> [   72.319951] remoteproc remoteproc1: 4a334000.pru is available
>>> [   72.335870] remoteproc remoteproc2: 4a338000.pru is available
>>> [  564.302719] remoteproc remoteproc1: powering up 4a334000.pru
>>> [  564.303391] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
>>> size 118908
>>> [  564.316303] remoteproc remoteproc1: registered virtio0 (type 7)
>>> [  564.316324] remoteproc remoteproc1: remote processor 4a334000.pru is 
>>> now up
>>> [  590.322924] remoteproc remoteproc1: stopped remote processor 
>>> 4a334000.pru
>>> [  594.762821] remoteproc remoteproc1: powering up 4a334000.pru
>>> [  594.763533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
>>> size 11
>>> [  594.777049] remoteproc remoteproc1: registered virtio0 (type