Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-16 Thread Greg Ercolano 
On 05/16/17 16:56, ercolano7...@gmail.com wrote:
> I did notice a few error messages using the OP's disk image + script..
> While the script ran, I saw these errors scroll by -- is this something I 
> should ignore?
> _
> [..]
> Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
> Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
> Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.   
>   <--
> Please install the linux-headers-4.4.27-ti-r62 package,   
>   <--
> or use the --kernelsourcedir option to tell DKMS where it's located   
>   <--
> Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. 
>   <--
> Please install the linux-headers-4.4.27-ti-r62 package,   
>   <--
> or use the --kernelsourcedir option to tell DKMS where it's located   
>   <--
> Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.  
>   <--
> Please install the linux-headers-4.4.27-ti-r62 package,   
>   <--
> or use the --kernelsourcedir option to tell DKMS where it's located   
>   <--
>[..]


 I think the solution here would be to include an "apt-get" in the prep 
script
 before this point to install the correct linux-headers-x.x. package, 
based
 on whatever new kernel was found during the upgrade process.

 In my case, after the reboot, I noticed the active kernel was the new one
 the prep script downloaded (4.4.27), as reported by 'uname -r'..
 so this seemed to be the appropriate command to install those headers:

apt-get install linux-headers-`uname -r`

 I'll see if I can work that into the prep_pru.sh script, and supply a 
patch.
 I imagine I'll have to replace the `uname -r` with the downloaded linux 
image value,
 as at that time the script is running, 'uname -r' will report the wrong 
kernel version.

 I should probably re-do the imaging procedure, and re-run the prep script
 from scratch with the change applied, as I'm not sure the prep_pru.sh 
script
 is designed to handle being run more than once (at least, not in its 
current
 incarnation, as it appears to append to .bashrc and /etc/rc.local without 
checking
 if the mods are already there..)

 Will try to follow up with what I find..

-- 
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/591B96AE.8090805%40seriss.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-16 Thread Greg Ercolano 
On 05/16/17 17:17, Greg Ercolano wrote:
> On 05/16/17 16:56, ercolano7...@gmail.com wrote:
>> I did notice a few error messages using the OP's disk image + script..
>> [..]
>> Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
>> Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
>> Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.  
>><--
>> Please install the linux-headers-4.4.27-ti-r62 package,  
>><--
>> or use the --kernelsourcedir option to tell DKMS where it's located  
>><--
>> Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.
>><--
>> Please install the linux-headers-4.4.27-ti-r62 package,  
>><--
>> or use the --kernelsourcedir option to tell DKMS where it's located  
>><--
> 
> [..]
>  In my case, after the reboot, I noticed the active kernel was the new one
>  the prep script downloaded (4.4.27), as reported by 'uname -r'..
>  so this seemed to be the appropriate command to install those headers:
> 
>   apt-get install linux-headers-`uname -r`
> [..]
>  Will try to follow up with what I find..

Hmm, so after the new kernel headers were installed, I verified
there's now a 'build' link in the modules directory for that kernel version
that wasn't there before:

# ls -la /lib/modules/4.4.*/build
lrwxrwxrwx 1 root root 36 Oct 26  2016 /lib/modules/4.4.27-ti-r62/build -> 
/usr/src/linux-headers-4.4.27-ti-r62   <--
lrwxrwxrwx 1 root root 35 May  5  2016 /lib/modules/4.4.9-ti-r25/build -> 
/usr/src/linux-headers-4.4.9-ti-r25

..which is good, because I know building device drivers need that link
to exist.

So I then retried making the project the prep_pru.sh command failed to 
build,
but still getting these weird errors:

root@beaglebone:~# export DTB=~/dtb-rebuilder/src/arm
root@beaglebone:~# cd /root/dtb-rebuilder/
root@beaglebone:~/dtb-rebuilder# make clean
  CLEAN   src/arm
root@beaglebone:~/dtb-rebuilder# make
  DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
Makefile:84: recipe for target 'all_arm' failed
make: *** [all_arm] Error 2

Does anyone know the solution for that?

-- 
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/591B9AFB.3090004%40seriss.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-16 Thread Robert Nelson 
On Tue, May 16, 2017 at 7:36 PM, Greg Ercolano  wrote:
> On 05/16/17 17:17, Greg Ercolano wrote:
>> On 05/16/17 16:56, ercolano7...@gmail.com wrote:
>>> I did notice a few error messages using the OP's disk image + script..
>>> [..]
>>> Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
>>> Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
>>> Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. 
>>> <--
>>> Please install the linux-headers-4.4.27-ti-r62 package, 
>>> <--
>>> or use the --kernelsourcedir option to tell DKMS where it's located 
>>> <--
>>> Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.   
>>> <--
>>> Please install the linux-headers-4.4.27-ti-r62 package, 
>>> <--
>>> or use the --kernelsourcedir option to tell DKMS where it's located 
>>> <--
>>
>> [..]
>>  In my case, after the reboot, I noticed the active kernel was the new 
>> one
>>  the prep script downloaded (4.4.27), as reported by 'uname -r'..
>>  so this seemed to be the appropriate command to install those headers:
>>
>>   apt-get install linux-headers-`uname -r`
>> [..]
>>  Will try to follow up with what I find..
>
> Hmm, so after the new kernel headers were installed, I verified
> there's now a 'build' link in the modules directory for that kernel 
> version
> that wasn't there before:
>
> # ls -la /lib/modules/4.4.*/build
> lrwxrwxrwx 1 root root 36 Oct 26  2016 /lib/modules/4.4.27-ti-r62/build -> 
> /usr/src/linux-headers-4.4.27-ti-r62   <--
> lrwxrwxrwx 1 root root 35 May  5  2016 /lib/modules/4.4.9-ti-r25/build -> 
> /usr/src/linux-headers-4.4.9-ti-r25
>
> ..which is good, because I know building device drivers need that link
> to exist.
>
> So I then retried making the project the prep_pru.sh command failed to 
> build,
> but still getting these weird errors:
>
> root@beaglebone:~# export DTB=~/dtb-rebuilder/src/arm
> root@beaglebone:~# cd /root/dtb-rebuilder/
> root@beaglebone:~/dtb-rebuilder# make clean
>   CLEAN   src/arm
> root@beaglebone:~/dtb-rebuilder# make
>   DTC src/arm/am437x-gp-evm.dtb
> FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
> Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
> make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
> Makefile:84: recipe for target 'all_arm' failed
> make: *** [all_arm] Error 2
>
> Does anyone know the solution for that?

sudo apt update
sudo apt install device-tree-compiler --reinstall

Which will install "mainline" dtc 1.4.4, no more of our dtc 1.4.1 +
patches.. It's all mainline dtc now!! ;)

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/CAOCHtYihhjvu5TTwpuCQDMt_ULt11EWNfjyVts1UHsffCuMr5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-17 Thread ercolano7777 
On Tuesday, May 16, 2017 at 7:11:33 PM UTC-7, RobertCNelson wrote:
>
> On Tue, May 16, 2017 at 7:36 PM, Greg Ercolano  > wrote: 
> > root@beaglebone:~/dtb-rebuilder# make 
> >   DTC src/arm/am437x-gp-evm.dtb 
> > FATAL ERROR: Unrecognized check name "unit_address_vs_reg"   
>   <-- 
> > Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed   
>   <-- 
> > make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1 
> > Makefile:84: recipe for target 'all_arm' failed 
> > make: *** [all_arm] Error 2 
> > 
> > Does anyone know the solution for that? 
>
> sudo apt update 
> sudo apt install device-tree-compiler --reinstall 
>
> Which will install "mainline" dtc 1.4.4, no more of our dtc 1.4.1 + 
> patches.. It's all mainline dtc now!! ;) 
>
>  
Thanks Robert, so I take it you might be saying that this command:

apt install device-tree-compiler --reinstall 

..could maybe replace all the following code in the OP's "prep_pru.sh" 
script:

__

#as per rnelson rebuild the dtbs with pru support as out ofthe box it is 
now longer supported, 
# the user needs to choose either uio_pruss or remote proc to enable 
otherwise it is not enabled.  Strange that no pru support is enabled by 
default.

#Essentially you need to edit one of the dts for the base dtb.  Hear we 
edit the basic default dtb.
cd ~/ && git clone https://github.com/RobertCNelson/dtb-rebuilder 
export DTB=~/dtb-rebuilder/src/arm
sed -i -e 's/\/\* #include \"am33xx-pruss-uio.dtsi\" \*\//#include 
\"am33xx-pruss-uio.dtsi\"/'   $DTB/am335x-boneblack.dts
#sed -i -e 's/#dtb=/dtb=am335x-boneblack-emmc-overlay.dtb/'  /boot/uEnv.txt
cd /root/dtb-rebuilder/ && make
cd /root/dtb-rebuilder/ && make KERNEL_VERSION=4.4.27-ti-r62 install
__

His script already runs apt update right at the top, and it is assumed to 
already be run as root, so the sudo shouldn't be needed)

I've been a C and assembly programmer since the 80's, but all of this with 
dtc is still pure greek to me.
I'm assuming the original intent was to install the latest git version of 
the dtc compiler, though I'm not sure what implications the sed command 
has, so I'd defer to you or the OP's opinions.

Arguably, the best thing would be to offer up a disk image instead of an 
image with patches applied from live repos.
I'm actually hoping to create such an image once I confirm a blinking light 
on the board.

-- 
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/6fc5e0c5-a9fd-464e-bae8-89811fd48225%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-17 Thread Greg Ercolano 
On 05/16/17 17:36, Greg Ercolano wrote:
> root@beaglebone:~/dtb-rebuilder# make
>   DTC src/arm/am437x-gp-evm.dtb
> FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
> Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
> make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
> Makefile:84: recipe for target 'all_arm' failed
> make: *** [all_arm] Error 2
> 
> Does anyone know the solution for that?

Google searches weren't helping me solve that one, so I dug into
the Makefile a bit.

Short answer seems to be to change this line in the Makefile:

-DTC_FLAGS += -Wno-unit_address_vs_reg
+#DTC_FLAGS += -Wno-unit_address_vs_reg

..when I did that, it breezed through the build without errors.

Will move onward to try to get an error free result.


DIGRESSION
==

Regarding figuring out how to solve the above, it was obvious 'make'
wasn't showing the commands being used to build the targets, so I wanted
to see what was going on when it failed.

The Makefile comments indicate there's some kind of convention to keeping
the noise of the build down, using two Makefile variables 'quiet' and 'Q'.

I found I could get make to show the commands being executed by changing
this section of the Makefile:

 ifeq ($(KBUILD_VERBOSE),1)
   quiet =
   Q =
 else
-  quiet=quiet_
-  Q = @
+  quiet=
+  Q =
 endif

 With that modification, running 'make' showed the full command
 being executed. So instead of just showing this:


DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"


 ..it now showed the full commands being executed:


  make ARCH=arm all_arch
  cpp -Wp,-MD,src/arm/.am437x-gp-evm.dtb.d.pre.tmp -nostdinc -Iinclude 
-Isrc/arm -Itestcase-data -undef -D__DTS__ -x assembler-with-cpp -o 
src/arm/.am437x-gp-evm.dtb.dts.tmp src/arm/am437x-gp-evm.dts ; /usr/bin/dtc -O 
dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm -Wno-unit_address_vs_reg -d 
src/arm/.am437x-gp-evm.dtb.d.dtc.tmp src/arm/.am437x-gp-evm.dtb.dts.tmp ; cat 
src/arm/.am437x-gp-evm.dtb.d.pre.tmp src/arm/.am437x-gp-evm.dtb.d.dtc.tmp > 
src/arm/.am437x-gp-evm.dtb.d
  FATAL ERROR: Unrecognized check name "unit_address_vs_reg"


 There's actually three commands being run in one line there;
 cpp, dts, and cat. The 'dts' line is the one that failed:

  /usr/bin/dtc -O dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm 
-Wno-unit_address_vs_reg -d src/arm/.am437x-gp-evm.dtb.d.dtc.tmp 
src/arm/.am437x-gp-evm.dtb.dts.tmp

 ..and there's the "-Wno-unit_address_vs_reg" flag that dtc was
 complaining about.

 The man page for dtc doesn't describe a -W flag, but I'm assuming
 it's a compiler warning flag of some kind, perhaps like gcc's.

-- 
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/591BB3A1.5090305%40seriss.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-17 Thread Gary Thomas 

On 2017-05-17 04:21, Greg Ercolano wrote:

On 05/16/17 17:36, Greg Ercolano wrote:

root@beaglebone:~/dtb-rebuilder# make
  DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
Makefile:84: recipe for target 'all_arm' failed
make: *** [all_arm] Error 2

Does anyone know the solution for that?


Google searches weren't helping me solve that one, so I dug into
the Makefile a bit.

Short answer seems to be to change this line in the Makefile:

-DTC_FLAGS += -Wno-unit_address_vs_reg
+#DTC_FLAGS += -Wno-unit_address_vs_reg

..when I did that, it breezed through the build without errors.

Will move onward to try to get an error free result.


DIGRESSION
==

Regarding figuring out how to solve the above, it was obvious 'make'
wasn't showing the commands being used to build the targets, so I wanted
to see what was going on when it failed.

The Makefile comments indicate there's some kind of convention to keeping
the noise of the build down, using two Makefile variables 'quiet' and 'Q'.

I found I could get make to show the commands being executed by changing
this section of the Makefile:

 ifeq ($(KBUILD_VERBOSE),1)
   quiet =
   Q =
 else
-  quiet=quiet_
-  Q = @
+  quiet=
+  Q =
 endif


This is just equivalent to 'make V=1'



 With that modification, running 'make' showed the full command
 being executed. So instead of just showing this:


DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"


 ..it now showed the full commands being executed:


  make ARCH=arm all_arch
  cpp -Wp,-MD,src/arm/.am437x-gp-evm.dtb.d.pre.tmp -nostdinc -Iinclude 
-Isrc/arm -Itestcase-data -undef -D__DTS__ -x assembler-with-cpp -o 
src/arm/.am437x-gp-evm.dtb.dts.tmp src/arm/am437x-gp-evm.dts ; /usr/bin/dtc -O dtb 
-o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm -Wno-unit_address_vs_reg -d 
src/arm/.am437x-gp-evm.dtb.d.dtc.tmp src/arm/.am437x-gp-evm.dtb.dts.tmp ; cat 
src/arm/.am437x-gp-evm.dtb.d.pre.tmp src/arm/.am437x-gp-evm.dtb.d.dtc.tmp > 
src/arm/.am437x-gp-evm.dtb.d
  FATAL ERROR: Unrecognized check name "unit_address_vs_reg"


 There's actually three commands being run in one line there;
 cpp, dts, and cat. The 'dts' line is the one that failed:

  /usr/bin/dtc -O dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm 
-Wno-unit_address_vs_reg -d src/arm/.am437x-gp-evm.dtb.d.dtc.tmp 
src/arm/.am437x-gp-evm.dtb.dts.tmp

 ..and there's the "-Wno-unit_address_vs_reg" flag that dtc was
 complaining about.

 The man page for dtc doesn't describe a -W flag, but I'm assuming
 it's a compiler warning flag of some kind, perhaps like gcc's.




--
Gary Thomas

--
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/51970ef6-57e1-1c70-4cc3-d47c33f6659e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-17 Thread Robert Nelson 
On Tue, May 16, 2017 at 9:41 PM,   wrote:
> On Tuesday, May 16, 2017 at 7:11:33 PM UTC-7, RobertCNelson wrote:
>>
>> On Tue, May 16, 2017 at 7:36 PM, Greg Ercolano  wrote:
>> > root@beaglebone:~/dtb-rebuilder# make
>> >   DTC src/arm/am437x-gp-evm.dtb
>> > FATAL ERROR: Unrecognized check name "unit_address_vs_reg"
>> > <--
>> > Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed
>> > <--
>> > make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
>> > Makefile:84: recipe for target 'all_arm' failed
>> > make: *** [all_arm] Error 2
>> >
>> > Does anyone know the solution for that?
>>
>> sudo apt update
>> sudo apt install device-tree-compiler --reinstall
>>
>> Which will install "mainline" dtc 1.4.4, no more of our dtc 1.4.1 +
>> patches.. It's all mainline dtc now!! ;)
>>
>
> Thanks Robert, so I take it you might be saying that this command:
>
> apt install device-tree-compiler --reinstall
>
> ..could maybe replace all the following code in the OP's "prep_pru.sh"
> script:
>
> __
>
> #as per rnelson rebuild the dtbs with pru support as out ofthe box it is now
> longer supported,
> # the user needs to choose either uio_pruss or remote proc to enable
> otherwise it is not enabled.  Strange that no pru support is enabled by
> default.
>
> #Essentially you need to edit one of the dts for the base dtb.  Hear we edit
> the basic default dtb.
> cd ~/ && git clone https://github.com/RobertCNelson/dtb-rebuilder
> export DTB=~/dtb-rebuilder/src/arm
> sed -i -e 's/\/\* #include \"am33xx-pruss-uio.dtsi\" \*\//#include
> \"am33xx-pruss-uio.dtsi\"/'   $DTB/am335x-boneblack.dts
> #sed -i -e 's/#dtb=/dtb=am335x-boneblack-emmc-overlay.dtb/'  /boot/uEnv.txt
> cd /root/dtb-rebuilder/ && make
> cd /root/dtb-rebuilder/ && make KERNEL_VERSION=4.4.27-ti-r62 install
> __
>
> His script already runs apt update right at the top, and it is assumed to
> already be run as root, so the sudo shouldn't be needed)
>
> I've been a C and assembly programmer since the 80's, but all of this with
> dtc is still pure greek to me.
> I'm assuming the original intent was to install the latest git version of
> the dtc compiler, though I'm not sure what implications the sed command has,
> so I'd defer to you or the OP's opinions.
>
> Arguably, the best thing would be to offer up a disk image instead of an
> image with patches applied from live repos.
> I'm actually hoping to create such an image once I confirm a blinking light
> on the board.

Actually this is now fixed with U-Boot overlays. (I just added the pru
options a week or two back)

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

and i've now just pushed the pru options:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

No rebuilding, just /boot/uEnv.txt editing..

>From /boot/uEnv.txt

###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_uio (mainline kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

pru_rproc is enabled by default, just comment the first and un-comment
the second and reboot..

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/CAOCHtYg37SBpc%2B5UU75EBfNHuABizp9rd1NrVdwP278dopEhfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-17 Thread William Hermans 
On Tue, May 16, 2017 at 7:41 PM,  wrote:

> I've been a C and assembly programmer since the 80's, but all of this with
> dtc is still pure greek to me.
> I'm assuming the original intent was to install the latest git version of
> the dtc compiler, though I'm not sure what implications the sed command
> has, so I'd defer to you or the OP's opinions.
>

Well device tree overlay source files are not C, or assembly either.
Although, you can use C syntax highlighting in your text editor of choice
to make your life easier. I tend to view overlay source files more as
something like xml, or some form of a markup language. Understanding the
source files though just takes time, and knowledge of how pin-muxing, and
several hardware aspect on this platform works.

How, I learned how the source files work, was to take one of the Universal
IO overlay source files, and deleted everything in it except the main
structure, and a single pin. At this point, you see all the different modes
a pin can function as, and things become a bit clearer. It also helps to
understand the hardware that you're trying to configure. Some of the
simpler overlay source files such as for RTC, or 1-wire. Studying these
should help one understand some things too. Such as how to load a driver
from an overlay file, or how to configure an I2C device bus address from an
overlay file. In the end it just takes time.

-- 
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/CALHSORrjJt67g5Y-g3zNJC0cOk76Uf%2BvjWZ2yLQpCqRw8Ub2Gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-17 Thread ercolano7777 
On 05/16/17 19:21, Greg Ercolano wrote:
> On 05/16/17 17:36, Greg Ercolano wrote:
>> root@beaglebone:~/dtb-rebuilder# make
>>   DTC src/arm/am437x-gp-evm.dtb
>> FATAL ERROR: Unrecognized check name 
"unit_address_vs_reg" <--
>> Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' 
failed <--
>> make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
>> Makefile:84: recipe for target 'all_arm' failed
>> make: *** [all_arm] Error 2
>>
>> Does anyone know the solution for that?
> 
> Short answer seems to be to change this line in the Makefile:
> 
> -DTC_FLAGS += -Wno-unit_address_vs_reg
> +#DTC_FLAGS += -Wno-unit_address_vs_reg
> 
> ..when I did that, it breezed through the build without errors.

OK, things went pretty smoothly after that; I now have
a blinking LED via PRU control. W00t!

A DISK IMAGE WITH EVERYTHING APPLIED


So as to make this easier for others, I've taken a snapshot
of my entire 4G disk image with the OP's script applied, and
put the resulting image here:


http://seriss.com/people/erco/beaglebone/beaglebone-black-surefire--debian-8.4-pru-example--05-16-2017--4gb-erco.img.xz



*SIZE: 973589464 bytes (928M)SHASUM: 
b36840a28618eb8d95545bb367e20212bae74230CKSUM: 3178223733 973589464*
Basically write that to an SDHC card and boot it (*don't flash*),
login as root and view the /root/README.txt to blink an LED
via PRU. No external dependencies.

When done, just run 'halt', and you can revert to your normal
flashed OS by removing the SDHC from the slot and rebooting.

If this is popular, I can re-post it as a top level post.

DETAILS
===

Breaking that down a bit, I have a BeagleBone Black (BBB) rev C.
Once the .xz image is downloaded:

1) unxz the disk image, and write the resulting .img
   to a micro SDHC card that's 4GB or larger.

2) Put the micro SDHC into the BBB's slot.

3) Power up the BBB with the micro SD card in the slot.
   **No need** to flash it or hold any buttons down during boot!
   Just do a *normal boot* with the micro SD card in the slot.

4) When it boots, login as root. (no password)

5) Refer to the ~root/README.txt file, but basically in the
   shell, run:





*modprobe uio_prussconfig-pin overlay BB-BONE-PRUcd 
/root/pru/pru-gcc-examples/blinking-led/host-uio./out/pload 
../pru/out/pru-core0.elf ../pru/out/pru-core1.elf*
   Those commands should all succeed.
   The last command runs the actual demo on the PRU's; it runs
   for about a minute then exits by itself.

   While it's running, an LED should be blinking at around 2Hz
   if wired between P9.27 and ground thru a 1K resistor under
   control of the PRU.

   When it finishes running, the LED stops blinking and the
   PRUs will stop. You can just run that last command again
   to re-run the demo to get the LED flashing again.

For step #1, I used an 8GB micro SDHC1 card I bought at the
Walgreens down the street for $6. These disks are cheap, so buy
a few so you can boot different OS images easily, and make backups.

For step #3, I found I could just boot the card without flashing.
This is *great* because you don't have to wipe your flashed OS.
You can boot just to test without messing up your installation.

For step #4, I had my BBB plugged into my router with an ethernet
cable, and ssh'ed into it as root from one of my other machines
using the DHCP assigned IP. I assume other techniques work too,
including the USB cable approach.

In root's home directory I put a README.txt file that
explains what to do:
___

RUNNING THE EXAMPLE
===
To blink some LEDs using the PRU, first these preparatory commands
need to have been run since the last boot:



*modprobe uio_prussconfig-pin overlay BB-BONE-PRU*
..and with that, these commands should load up PRU0 and PRU1
with code to blink an LED:



*cd /root/pru/pru-gcc-examples/blinking-led/host-uio
./out/pload ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf*
Assuming there are no errors, you should see an LED flashing
if connected between GPIO pin P9.27 and ground through an appropriate
current limiting resistor.
___

 As an added detail:

* * *
 You can use this wiring diagram for wiring info:
 http://beagleboard.org/static/images/cape-headers.png
 Should that image go stale, holding the BBB with the
 ethernet plug at 12 o'clock, P9 is the connector on
 the left. The lower left pinhole is pin 45 and is GND.
 The pinhole 10 holes up from the lower/left is pin 27
 which is the GPIO output we use. An "ascii art" schematic:

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-18 Thread Greg Ercolano 
On 05/17/17 13:42, William Hermans wrote:
> On Tue, May 16, 2017 at 7:41 PM,  > wrote:
> I've been a C and assembly programmer since the 80's, but all of this
> with dtc is still pure greek to me. I'm assuming the original intent
> was to install the latest git version of the dtc compiler, though I'm
> not sure what implications the sed command has, so I'd defer to you or
> the OP's opinions.
> 
> Well device tree overlay source files are not C, or assembly either.
> [..] I tend to view overlay source files more as something like xml,
> or some form of a markup language.


Thanks -- I appreciate the XML analogy.

I did watch Jason Kridner's videos a few weeks ago which preped me
for learning the device tree file format; I was kinda ready for that
hurdle actually.

What I wasn't ready for was dealing with the internals of the
tools themselves. In the case of dtc, errors like "unit_address_vs_reg"
and things like uboot vs boot, and the language of the various tool
version numbers, what's mainline and what isn't..

Just couldn't grok, after only recently emerging from the wringer
of the last several days.

It's not just dtc I was encountering trouble with; it's been days
of hitting walls with other tools as well; my browser history tells
the sad tail of echo commands causing "kernel oops" errors, the pru
loader tossing up "prussdrv_open() failed" errors.. on and on.

The possible solutions to these issues led everywhere; get this
newer kernel, build this newer module, rebuild blobs, tweak boot flags..
it was supremely overwhelming and depressing.

What's wonderful about starting with the OP's disk image + script
is suddenly the sky cleared; having immediate success (minor bumps)
instead of walls of errors -- I could focus on the task at hand;
writing C code to run the PRUs.

Took hours to achieve success, instead of days achieving none.

BTW, this config-pin tool seems like maybe a way to avoid the
device tree stuff a bit; I see the LED flash example uses this.

Seems promising for my end use case where I just need to assign
GPIO pins to be in/out, and under PRU vs linux control. Its options
are kinda exactly what I need.

> C syntax highlighting in your text editor of choice to make your life easier.

Good idea -- I see there's a few vim syntax files for .dts files, e.g.
https://github.com/vim/vim/blob/master/runtime/syntax/dts.vim

In fact, with the OP's resulting disk image (and the one I posted),
using ':syntax on' in vim while viewing a .dts file seems to be
highlighting meaningfully, apparently due to this file:

/usr/share/vim/vim74/syntax/dts.vim

> Understanding the source files though just takes time, and knowledge
> of how pin-muxing, and several hardware aspect on this platform works.

Do you think the config-pin tool is a way around .dts?

If config-pin didn't exist, I'd probably write it just to avoid
having to manually derive hex codes from diagrams. (Huh, it's
a "dash" script.. cool. Was expecting python..!)

I see also someone made a web page that generates .dts,
using pulldown menus to select GPIO pins and in/out.

I like the promise of config-pin because it can be scripted;
end users could read/tweak its arguments, and a script could
check for errors and take alternative execution paths, and
print meaningful warnings on the user's console, instead of
mixed in with the voluminous output of dmesg and the syslog.

> How, I learned how the source files work, was to take one of the
> Universal IO overlay source files, and deleted everything in it
> except the main structure, and a single pin. At this point,
> you see all the different modes a pin can function as, and things
> become a bit clearer.

Cool -- if config-pin doesn't deliver for me, I'll do that!

Sounds like good advice to start with the dts file.. I take
it you mean the dts equivalent of the /lib/firmware/univ-all-00A0?

> It also helps to understand the hardware that you're trying to
> configure. Some of the simpler overlay source files such as for
> RTC, or 1-wire. Studying these should help one understand some
> things too. Such as how to load a driver from an overlay file,
> or how to configure an I2C device bus address from an overlay file.
> In the end it just takes time.

Interesting; I wasn't aware you can control the load of
device driver modules from dtc files.

I'm kinda used to using modprobe/insmod/rmmod commands
so that I can script them to check for errors. Kernel designers

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-18 Thread William Hermans 
On Wed, May 17, 2017 at 8:35 PM, Greg Ercolano  wrote:

> > . . .
>

So a lot of text there to "Wade" through so I'll try to answer the
questions you have in order. Without the "Sea of text" ;)

I think Universal IO, which includes the shell script config-pin is a
really cool tool for getting started. Especially, when all you want to do
is get down to writing code for the hardware. However, at the same time I
strongly feel that it is not a permanent solution for configuring the
hardware, especially for a production system. For many reasons, partly
because there can be some glitches, and partly because now we have uboot
overlays, that one can load through the second stage bootloader. Which also
means, for a production system you can have your pins, and hardware
configured exactly how it needs to be. Prior to Linux being up and running.
If you script config-pin, this has to be done after Linux is running.

And . . actually, I think that was your only questions. I would like to add
some things however. Let's take this:
/* P8_07 (ZCZ ball R7 ) */
P8_07_default_pin: pinmux_P8_07_default_pin {
pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive */

This is just part of configuring a pin. Obviously for P8_07. So for pins
that can be operating in GPIO mode. This will be the first entry in any of
the universal io overlay files. The first line after the comment is pretty
much just a "#define", or a "prototype" definition of the pin in question.
Kind of like prototyping a function in C. The second line after the comment
is the actual pin information. 0x090 being the pin, which is a kernel pin
identifier I think. The second number 0x37 is the mux, and pullup mode( put
simply ). You can read the TRM and get a much better explanation of the mux
/ pullup mode register.

Anyway, check this out.
https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/board/am335x-bbw-bbb-base.h#L17

The point here, if you #include Robert's header file, you can use all the
BONE_Px_xx #defines in place of the actual "kernel pin value". Which can(
does for me ) remove a lot of tedious work trying to memorize, or digging
through documentation just to get a pin to work the way you want.
Additionally, there is another header file, which #define mux, and other
register modes. These two headers alone can take a lot of learning pressure
off your shoulders. Then if like me, you do know C very well ( I'm assuming
you do ), you can read through these source header files, along with the
TRM, or whatever documentation that makes the most sense to you. Suddenly,
that light at the end of the tunnel starts to appear. Pullup modes, you
simply OR together ( FOO | BAR )

And yeah, I guess there was another question in there. Yes, any dt file
starting with "univ "including "univ" or "universal" will be a universal IO
related overlay. Some originally written by Charles S( Mug cooler ;) ). or
Robert Nelson.

Anyway, right now I am kind of busy with work related code. Bu maybe,
sometime soon I can make a working device tree overlay, with an explanation
of the file for one pin. Put it on my blog page, and link back to it. The
problem with that, is it often takes more work to create a post, than it
does to actually just write the code, and *maybe* explain it, if needed.

-- 
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/CALHSORpYVGKZVzptX%3D13QVczmERqQnvE9i%2B4YNRk%3DyJEU-p5HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread ercolano7777 

On Thursday, May 18, 2017 at 3:58:03 PM UTC-7, William Hermans wrote:
>
> So a lot of text there to "Wade" through so I'll try to answer the 
> questions you have in order. Without the "Sea of text" ;)
>

No walls of text; OK, will try to keep it shorter.

I think Universal IO, which includes the shell script config-pin is a 
> really cool tool for getting started. Especially, when all you want to do 
> is get down to writing code for the hardware. However, at the same time I 
> strongly feel that it is not a permanent solution for configuring the 
> hardware, especially for a production system. For many reasons, partly 
> because there can be some glitches, and partly because now we have uboot 
> overlays, that one can load through the second stage bootloader. Which also 
> means, for a production system you can have your pins, and hardware 
> configured exactly how it needs to be. Prior to Linux being up and running. 
> If you script config-pin, this has to be done after Linux is running.
>

Definitely going to consider those concerns, and keep an eye out for 
them in my setup.

In my case I envisioned config-pin in /etc/rc.local to run once, and be 
able to run it in real time so field personnel can change/experiment. For 
instance to make a change for a pin to have a pull-up instead of without 
one.

I read dev tree files can only be loaded on boot (?), IIRC the binary 
is loaded ahead of the kernel in ram by the boot loader, so I think dev 
cycle for dev tree files is harder for the field person, as a recompile + 
reboot is needed each time. It's hard enough getting field people to just 
edit config files.

I'd also like to avoid field people seeing two ways of doing things. 
During support calls, one could compete with the other in unpredictable 
ways.. better to provide only one way to do something.


Let's take this:
> /* P8_07 (ZCZ ball R7 ) */ 
> P8_07_default_pin: pinmux_P8_07_default_pin { 
> pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive */
>
> This is just part of configuring a pin. Obviously for P8_07. So for pins 
> that can be operating in GPIO mode. This will be the first entry in any of 
> the universal io overlay files. The first line after the comment is pretty 
> much just a "#define", or a "prototype" definition of the pin in question. 
> Kind of like prototyping a function in C. The second line after the comment 
> is the actual pin information. 0x090 being the pin, which is a kernel pin 
> identifier I think. The second number 0x37 is the mux, and pullup mode( put 
> simply ). You can read the TRM and get a much better explanation of the mux 
> / pullup mode register.
>

I see -- I'll do some reading to try to figure out what actually parses 
this info on boot, as I like to understand what tool/driver is looking at 
the file I'm configuring, in case I need to RTSL to figure out what's wrong 
when errors occur. If it's a built in kernel driver (cape driver maybe?)

I did read petazzoni's "Device Tree For Dummies" last night to try to 
determine the big picture, but it really lost me somewhere in the middle. 
Just too much.. stuff.. I didn't want to know or track down. It assumes a 
knowledge of the modern kernel terminology that I just don't have.

Anyway, check this out. 
> https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/board/am335x-bbw-bbb-base.h#L17
>  
> The point here, if you #include Robert's header file, you can use all the 
> BONE_Px_xx #defines in place of the actual "kernel pin value".
>

I see, so I take it these two lines would be equivalent, the lower one 
my construction:

pinctrl-single,pins = <0x090 0x37>; }; /* Mode 7, Pull-Up, RxActive */
pinctrl-single,pins = ; }; /* Mode 7, Pull-Up, RxActive */

..yes, symbols would be better than hex.

Which can( does for me ) remove a lot of tedious work trying to memorize, 
> or digging through documentation just to get a pin to work the way you 
> want. Additionally, there is another header file, which #define mux, and 
> other register modes. These two headers alone can take a lot of learning 
> pressure off your shoulders. Then if like me, you do know C very well ( I'm 
> assuming you do ), you can read through these source header files, along 
> with the TRM, or whatever documentation that makes the most sense to you. 
> Suddenly, that light at the end of the tunnel starts to appear. Pullup 
> modes, you simply OR together ( FOO | BAR )
>
 
Yes, it'd be much easier on the eyes if 0x37 could be a few macros 
OR'ed together instead. Would those values be found in, just guessing: 
https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/pinctrl/omap.h
 
 ? (Same project, different file)

I wouldn't mind magic numbers if the reference table was in the same 
document (ascii art preferred to a link, as links go stale).

For fun, I tried to determine what 0x37 means. You referred to the 
"TRM", which I take

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread ercolano7777 


On Saturday, May 20, 2017 at 4:42:46 PM UTC-7, ercola...@gmail.com wrote:
>
>
> On Thursday, May 18, 2017 at 3:58:03 PM UTC-7, William Hermans wrote:
>
>> [..]along with the TRM, or whatever documentation that makes the most 
>> sense to you. [..]
>>
>  
> For fun, I tried to determine what 0x37 means. You referred to the "TRM", 
> which I take to mean the Sitara Tech Ref Manual (rev c).. that ~2300 page 
> monster! ;) Spent a bit of time in there, but was unable to figure out 
> which table was relevant.
>

Oh, OK, I think "the TRM" must refer to this one 
 instead (I think), while 
bigger (4300 pages), it's a bit easier on my eyes, as it seems to have info 
more relevant to a software person than this other one 

 
I was looking at which seems more hardware somehow. I'm still a bit new to 
this all.

The latter was the first link google returned when searching for 
"beaglebone technical reference manual".. they call it the 'system 
technical reference manual', but seems to be a different thing.

The former also has a good description of the on-chip hardware peripherals 
(PWM, UART, etc).

-- 
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/b9b835de-5fbf-4b7b-a71c-20ddfb1f3eb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread William Hermans 
No, prior to uboot overlays, overlays were loaded from the initrd, at best.
Also we need to understand that the board file(also an overlay of sorts -
but required )is seperate from all this discussion.

 I do not understand why you would have "field people" playing around with
hardware overlays though. Once your hardware is finalized, it should never
change. Which is one small reason why I personally find Universal IO
unnecessary for my own purposes.

The problem I've seen with explanations, and documentation on device tree,
is that no one explains it really well. Additionally, as a new player into
device tree overlays. Its not clear where to get information from. See, you
need to understand the pin-ctrl subsystem, gpio subsystem . . . list goes
one, and on . . .A lot of this information has to be found from the Linux
kernel source documentation.HOWEVER, you do not necessarily need to
memorize all of this. We ( programmers ) just need a reference that does
not goes on, and on for days about silly details we do not need to know to
get our jobs done. Nothing like this exists.

Anyway, in order to learn, you need to "do".

-- 
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/CALHSORp%3DXhCftd6%3D5CyxbM3oa7wRo4rPpEV28OZ%3DBWUXcDXQXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread William Hermans 
System reference manual SRM, Technical reference manual TRM.

On Sat, May 20, 2017 at 5:58 PM, William Hermans  wrote:

> No, prior to uboot overlays, overlays were loaded from the initrd, at
> best. Also we need to understand that the board file(also an overlay of
> sorts - but required )is seperate from all this discussion.
>
>  I do not understand why you would have "field people" playing around with
> hardware overlays though. Once your hardware is finalized, it should never
> change. Which is one small reason why I personally find Universal IO
> unnecessary for my own purposes.
>
> The problem I've seen with explanations, and documentation on device tree,
> is that no one explains it really well. Additionally, as a new player into
> device tree overlays. Its not clear where to get information from. See, you
> need to understand the pin-ctrl subsystem, gpio subsystem . . . list goes
> one, and on . . .A lot of this information has to be found from the Linux
> kernel source documentation.HOWEVER, you do not necessarily need to
> memorize all of this. We ( programmers ) just need a reference that does
> not goes on, and on for days about silly details we do not need to know to
> get our jobs done. Nothing like this exists.
>
> Anyway, in order to learn, you need to "do".
>

-- 
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/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread Gerald Coley 
I decided not to copy what was in the TRM into the SRM. That is why the SRM is 
specific to the BBB. And the TRM gets updated failry often by TI.

Gerald


From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of William Hermans
Sent: Saturday, May 20, 2017 8:00 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Re: Surefire PRU - Setup.

System reference manual SRM, Technical reference manual TRM.

On Sat, May 20, 2017 at 5:58 PM, William Hermans 
mailto:yyrk...@gmail.com>> wrote:
No, prior to uboot overlays, overlays were loaded from the initrd, at best. 
Also we need to understand that the board file(also an overlay of sorts - but 
required )is seperate from all this discussion.

 I do not understand why you would have "field people" playing around with 
hardware overlays though. Once your hardware is finalized, it should never 
change. Which is one small reason why I personally find Universal IO 
unnecessary for my own purposes.
The problem I've seen with explanations, and documentation on device tree, is 
that no one explains it really well. Additionally, as a new player into device 
tree overlays. Its not clear where to get information from. See, you need to 
understand the pin-ctrl subsystem, gpio subsystem . . . list goes one, and on . 
. .A lot of this information has to be found from the Linux kernel source 
documentation.HOWEVER, you do not necessarily need to memorize all of this. We 
( programmers ) just need a reference that does not goes on, and on for days 
about silly details we do not need to know to get our jobs done. Nothing like 
this exists.
Anyway, in order to learn, you need to "do".

--
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<mailto:beagleboard+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com<https://groups.google.com/d/msgid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

-- 
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/a67232f2a5a94c10abc16cc8ff83aa70%40winhexbeus11.winus.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread William Hermans 
Greg,

You know what. If I were you, I would get a Beaglebone black or green, and
make learning about it your favorite hobby. This way, you could experiment
with various things, until you're happy with what you end up using.

If memory is serving me correctly yes, you're using a blue. Yes, yes, but
the hardware is largely the same, and most if not all the software will be
exactly the same.

So yes, buy a beaglebone, take it home, and start experimenting. Then I
would probably not worry about HAVING to have hardware connected up with
it. There is a lot you can do by experimenting with software only. How, and
where to explore the GPIO subsystem. Which will then lead to being able to
tell if you've configured your overlay file at boot correctly. etc, etc.

On Sat, May 20, 2017 at 6:01 PM, Gerald Coley 
wrote:

> I decided not to copy what was in the TRM into the SRM. That is why the
> SRM is specific to the BBB. And the TRM gets updated failry often by TI.
>
>
>
> Gerald
>
>
>
>
>
> *From:* beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com]
> *On Behalf Of *William Hermans
> *Sent:* Saturday, May 20, 2017 8:00 PM
> *To:* beagleboard@googlegroups.com
> *Subject:* Re: [beagleboard] Re: Surefire PRU - Setup.
>
>
>
> System reference manual SRM, Technical reference manual TRM.
>
>
>
> On Sat, May 20, 2017 at 5:58 PM, William Hermans 
> wrote:
>
> No, prior to uboot overlays, overlays were loaded from the initrd, at
> best. Also we need to understand that the board file(also an overlay of
> sorts - but required )is seperate from all this discussion.
>
>  I do not understand why you would have "field people" playing around with
> hardware overlays though. Once your hardware is finalized, it should never
> change. Which is one small reason why I personally find Universal IO
> unnecessary for my own purposes.
>
> The problem I've seen with explanations, and documentation on device tree,
> is that no one explains it really well. Additionally, as a new player into
> device tree overlays. Its not clear where to get information from. See, you
> need to understand the pin-ctrl subsystem, gpio subsystem . . . list goes
> one, and on . . .A lot of this information has to be found from the Linux
> kernel source documentation.HOWEVER, you do not necessarily need to
> memorize all of this. We ( programmers ) just need a reference that does
> not goes on, and on for days about silly details we do not need to know to
> get our jobs done. Nothing like this exists.
>
> Anyway, in order to learn, you need to "do".
>
>
>
> --
> 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/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%
> 3D9MQAkeRUovrw%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/a67232f2a5a94c10abc16cc8ff83aa
> 70%40winhexbeus11.winus.mail
> <https://groups.google.com/d/msgid/beagleboard/a67232f2a5a94c10abc16cc8ff83aa70%40winhexbeus11.winus.mail?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALHSORr_SNNF%3DaHV-P8k0s59PM%3DUL39ZdQPgW6FtXpE7jr6FQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread William Hermans 
By the way these are my own preffered "pin mux mode" "spread sheet" PDF
files for working with various pins:
https://github.com/wphermans/bb-info/blob/master/BeagleboneBlackP8HeaderPinMuxModes.pdf

I do not recall who made these, but links in the PDF's themselves lead back
to who created them. Whom also derived the information in these files from
Derrek Molloy.

So I do not claim the material at all. I just wanted a location that was
easy for me to find, and would never go away. My git seemed to be as good a
place as any, for me.

On Sat, May 20, 2017 at 6:14 PM, William Hermans  wrote:

> Greg,
>
> You know what. If I were you, I would get a Beaglebone black or green, and
> make learning about it your favorite hobby. This way, you could experiment
> with various things, until you're happy with what you end up using.
>
> If memory is serving me correctly yes, you're using a blue. Yes, yes, but
> the hardware is largely the same, and most if not all the software will be
> exactly the same.
>
> So yes, buy a beaglebone, take it home, and start experimenting. Then I
> would probably not worry about HAVING to have hardware connected up with
> it. There is a lot you can do by experimenting with software only. How, and
> where to explore the GPIO subsystem. Which will then lead to being able to
> tell if you've configured your overlay file at boot correctly. etc, etc.
>
> On Sat, May 20, 2017 at 6:01 PM, Gerald Coley 
> wrote:
>
>> I decided not to copy what was in the TRM into the SRM. That is why the
>> SRM is specific to the BBB. And the TRM gets updated failry often by TI.
>>
>>
>>
>> Gerald
>>
>>
>>
>>
>>
>> *From:* beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com]
>> *On Behalf Of *William Hermans
>> *Sent:* Saturday, May 20, 2017 8:00 PM
>> *To:* beagleboard@googlegroups.com
>> *Subject:* Re: [beagleboard] Re: Surefire PRU - Setup.
>>
>>
>>
>> System reference manual SRM, Technical reference manual TRM.
>>
>>
>>
>> On Sat, May 20, 2017 at 5:58 PM, William Hermans 
>> wrote:
>>
>> No, prior to uboot overlays, overlays were loaded from the initrd, at
>> best. Also we need to understand that the board file(also an overlay of
>> sorts - but required )is seperate from all this discussion.
>>
>>  I do not understand why you would have "field people" playing around
>> with hardware overlays though. Once your hardware is finalized, it should
>> never change. Which is one small reason why I personally find Universal IO
>> unnecessary for my own purposes.
>>
>> The problem I've seen with explanations, and documentation on device
>> tree, is that no one explains it really well. Additionally, as a new player
>> into device tree overlays. Its not clear where to get information from.
>> See, you need to understand the pin-ctrl subsystem, gpio subsystem . . .
>> list goes one, and on . . .A lot of this information has to be found from
>> the Linux kernel source documentation.HOWEVER, you do not necessarily need
>> to memorize all of this. We ( programmers ) just need a reference that does
>> not goes on, and on for days about silly details we do not need to know to
>> get our jobs done. Nothing like this exists.
>>
>> Anyway, in order to learn, you need to "do".
>>
>>
>>
>> --
>> 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/ms
>> gid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_
>> K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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/ms
>> gid/beagleboard/a67232f2a5a94c10abc16cc8ff83aa70%
>> 40winhexbeus11.winus.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-20 Thread William Hermans 
oops, https://github.com/wphermans/bb-info is the top most path . . .

On Sat, May 20, 2017 at 6:27 PM, William Hermans  wrote:

> By the way these are my own preffered "pin mux mode" "spread sheet" PDF
> files for working with various pins: https://github.com/wphermans/
> bb-info/blob/master/BeagleboneBlackP8HeaderPinMuxModes.pdf
>
> I do not recall who made these, but links in the PDF's themselves lead
> back to who created them. Whom also derived the information in these files
> from Derrek Molloy.
>
> So I do not claim the material at all. I just wanted a location that was
> easy for me to find, and would never go away. My git seemed to be as good a
> place as any, for me.
>
> On Sat, May 20, 2017 at 6:14 PM, William Hermans 
> wrote:
>
>> Greg,
>>
>> You know what. If I were you, I would get a Beaglebone black or green,
>> and make learning about it your favorite hobby. This way, you could
>> experiment with various things, until you're happy with what you end up
>> using.
>>
>> If memory is serving me correctly yes, you're using a blue. Yes, yes, but
>> the hardware is largely the same, and most if not all the software will be
>> exactly the same.
>>
>> So yes, buy a beaglebone, take it home, and start experimenting. Then I
>> would probably not worry about HAVING to have hardware connected up with
>> it. There is a lot you can do by experimenting with software only. How, and
>> where to explore the GPIO subsystem. Which will then lead to being able to
>> tell if you've configured your overlay file at boot correctly. etc, etc.
>>
>> On Sat, May 20, 2017 at 6:01 PM, Gerald Coley 
>> wrote:
>>
>>> I decided not to copy what was in the TRM into the SRM. That is why the
>>> SRM is specific to the BBB. And the TRM gets updated failry often by TI.
>>>
>>>
>>>
>>> Gerald
>>>
>>>
>>>
>>>
>>>
>>> *From:* beagleboard@googlegroups.com [mailto:beagleboard@googlegrou
>>> ps.com] *On Behalf Of *William Hermans
>>> *Sent:* Saturday, May 20, 2017 8:00 PM
>>> *To:* beagleboard@googlegroups.com
>>> *Subject:* Re: [beagleboard] Re: Surefire PRU - Setup.
>>>
>>>
>>>
>>> System reference manual SRM, Technical reference manual TRM.
>>>
>>>
>>>
>>> On Sat, May 20, 2017 at 5:58 PM, William Hermans 
>>> wrote:
>>>
>>> No, prior to uboot overlays, overlays were loaded from the initrd, at
>>> best. Also we need to understand that the board file(also an overlay of
>>> sorts - but required )is seperate from all this discussion.
>>>
>>>  I do not understand why you would have "field people" playing around
>>> with hardware overlays though. Once your hardware is finalized, it should
>>> never change. Which is one small reason why I personally find Universal IO
>>> unnecessary for my own purposes.
>>>
>>> The problem I've seen with explanations, and documentation on device
>>> tree, is that no one explains it really well. Additionally, as a new player
>>> into device tree overlays. Its not clear where to get information from.
>>> See, you need to understand the pin-ctrl subsystem, gpio subsystem . . .
>>> list goes one, and on . . .A lot of this information has to be found from
>>> the Linux kernel source documentation.HOWEVER, you do not necessarily need
>>> to memorize all of this. We ( programmers ) just need a reference that does
>>> not goes on, and on for days about silly details we do not need to know to
>>> get our jobs done. Nothing like this exists.
>>>
>>> Anyway, in order to learn, you need to "do".
>>>
>>>
>>>
>>> --
>>> 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/ms
>>> gid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D
>>> %3D9MQAkeRUovrw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/beagleboard/CALHSORrAaF4Z%2B%3DUZRq%2Bi_oMFRM_K88noC7y5D%3D9MQAkeRUovrw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-21 Thread ercolano7777 
On Saturday, May 20, 2017 at 5:59:40 PM UTC-7, William Hermans wrote:
>
> System reference manual SRM, Technical reference manual TRM.
>

 Ah, OK -- it's confusing though; searching for "beaglebone technical 
reference manual" took me to this beagleboard.org page 
 that has:

BeagleBone Black System *Technical Reference Manual*

Hopefully you can see why I was confused.. I didn't realize the 
presence of the word "system" made that wrong, but apparently that takes 
one to "the SRM".

It's kinda hard to find this TRM when you're on the outside looking in; 
I looked elsewhere on the beagleboard.org site under "hardware support 
", "software support 
", and "Hardware Specs 
and Materials ", and "FAQ 
" with no luck searching for 
"technical reference manual" or "SRM" or "TRM". I'd think the abbreviations 
would at least be in the FAQ. Otherwise, how else would one know?

Went back to google, and tried including some extra terms that I know 
are in the TRM, like "interconnects" and "PWM". When I did that, I was able 
to find what I *think* is the right pdf file(?):  
http://mythopoeic.org/BBB-PRU/am335x_techref.pdf

I'll see if I can contact the beagleboard.org folks to see if they can 
include terms TRM and SRM, and perhaps reword the reference to the "System 
Technical Reference Manual" to instead be, maybe "System Reference Manual 
(SRM)". There's some email contacts under "About Us", so I'll try that.

-- 
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/00f1d82c-8a14-4603-9814-0f94b15d7a51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-21 Thread ercolano7777 


On Saturday, May 20, 2017 at 6:14:23 PM UTC-7, William Hermans wrote:
>
> Greg, 
>
> You know what. If I were you, I would get a Beaglebone black or green, and 
> make learning about it your favorite hobby. This way, you could experiment 
> with various things, until you're happy with what you end up using.
>

It's certainly been my hobby for the week. It was ok once I got it working, 
but I got very close a few times to tossing in the towel when the tools 
weren't working. Other folks 
 have 
apparently run into this too and given up, including a friend of mine who 
turned me on to the BBB before he actually tried it and hit similar walls.

The OP of this thread has been great though -- powered me past those road 
blocks with the flashed OS and latest debian from TI. Started moving much 
more quickly after that.
 

>
> If memory is serving me correctly yes, you're using a blue.
>

Nope, I have a black only. Didn't realize there was a blue, actually. Only 
knew about the green alternative.

Sorry; I've been using the term "BBB" assuming that referred exclusively to 
the black. But I can see where if there's also a product called "blue", BBB 
might refer to that too.. gah. Sorry if that confused anyone; all my 
replies have been *only* about the black.

So yes, buy a beaglebone, take it home, and start experimenting. Then I 
> would probably not worry about HAVING to have hardware connected up with 
> it. There is a lot you can do by experimenting with software only. How, and 
> where to explore the GPIO subsystem.
>

Ya, though I was hitting walls with that too (the black, no hardware 
attached to it other than the board itself); ram demos weren't running, as 
they threw up various errors from either the loader tool (open errors) or 
errors from the echo commands that geneated "write errors" that were trying 
to trigger device tree files that weren't loading for some reason. Also I 
tried the GPIO demos without an LED hooked up just to see it run, but was 
getting similar errors (prussdrv_open() failed, etc), so I didn't even 
bother with hardware until the OP got me past that.

Hoping to be spinning stepper motors tonight via the PRU.. looking forward 
to it!

-- 
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/d9805459-6206-45aa-9006-ce4fdef1ae78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-21 Thread ercolano7777 


On Saturday, May 20, 2017 at 6:27:31 PM UTC-7, William Hermans wrote:
>
> By the way these are my own preffered "pin mux mode" "spread sheet" PDF 
> files for working with various pins: 
> https://github.com/wphermans/bb-info/blob/master/BeagleboneBlackP8HeaderPinMuxModes.pdf
>

Thanks! Yes, there's so many of these, some with colors that are kinda hard 
to read because the colors are a bit too bold.

Great; I'll likely copy/paste that into a .txt file, as I like to edit code 
in vi over ssh, and pull lines from tables like this with grep. I prefer to 
develop locally on devices when possible via the terminal, and *avoid* IDEs 
and cross compiling from workstations unless there's no other choice.

-- 
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/92cadad8-5791-4f77-bb55-7f1e6c0bec3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-21 Thread ercolano7777 
On Saturday, May 20, 2017 at 5:58:14 PM UTC-7, William Hermans wrote:
>
>  I do not understand why you would have "field people" playing around with 
> hardware overlays though. Once your hardware is finalized, it should never 
> change. Which is one small reason why I personally find Universal IO 
> unnecessary for my own purposes.
>

I can explain that..

In my case I'm supplying computer software/hardware packages to control old 
film equipment called optical printers 
. These are heavy iron 
monsters with lots of big AC running throughout. They used to be used for 
special 
effects , but are now used mainly for 
film restoration, conversions, and archival. These machines used to be 
manually run and used mechanical transmissions, and were slowly 
computerized during the 80's when stepper motor control became popular.

The situation is my software/hardware combo is a starting point, and local 
engineers usually wire it all up, as there's a lot of AC 115 and 220 being 
controlled by the interface software.

They will be the ones that define whether they need to assign some of the 
GPIO bits for input or output, assigning them to either monitor motor 
homing sensors , or outputs to 
control custom filter wheels 
,
 
timing lights and film tension motors. Config files 
 on the computer 
define what are inputs and outputs my software controls. And during 
shooting, they might need to add a motor. Or a motor might crap out, and so 
to limp through production they'd need to disable one of the outputs on the 
fly and use it for some other purpose.

That's the application, anyway.. it has to be field modifiable, it's not a 
fixed design, i.e. not a "cape".

I used to (and still use) DOS machines with ISA GPIO cards 
 (usually 8255 
based), and DOS software I wrote back in 1987 (mostly C, some 8086 assembly 
as the DOS device driver for the stepper motors), some of my company's 
custom hardware 
, and 
some third party 
 
hardware. And the customer often supplies their own hardware 

 
that I help them design by supplying recommended wiring diagrams 
 and sometimes have to 
get in there with a soldering iron if their own folks aren't available 
(often hired independent contractors). These are the folks that have to be 
able to edit files on their own.

I do a lot of other software that pays the bills, but this particular old 
school project is a bit more hardware oriented, and DOS is showing its age 
(as are the ISA cards), so I'm hoping to port this whole thing to a 
beaglebone black, which can replace the DOS machine and 3rd party stepper 
card which is becoming hard to come by. 


-- 
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/a50f5bb5-13c3-430d-b01b-99e1df4dc9a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

2017-05-21 Thread William Hermans 
Sounds like fun. GPIO is super easy on this platform, once you know how the
GPIO subsystem works. PWM and ADC is a little more complicated. but not
much. PWM can be a bit of a bugger, because some of the examples do not
really work( overlays ). With PWM it becomes an exercise of wills, as you
the developer find the right example overlay, and have that "aha!" moment.
That's the software side of it anyhow.

So we can not really compare this platform to another. Especially the rPI.
As the rPI has limited IO capabilities by comparison. Then no pin muxing
that I'm aware of. So overlays are quite different. Once you get the
various aspect down, it'll get really easy for you. In software.

On the hardware side of things, this platform might be a bit picky. But as
long as the engineer pays attention to detail, as one should anyhow. There
should not be any problems. Luckily for me, I do not have to deal with the
hardware. :)

-- 
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/CALHSORoCuQEsyi2rtKqPQOqZxjUVFc%3Dr94%3D_hnyYUQy7D%3Dr4Hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.