Re: [beagleboard] How to enable /dev/uio for PRU communication on Debian 9.2 kernel 4.9.54-ti-r68 ?

[Jason Kridner]

On Friday, March 23, 2018 at 9:54:19 PM UTC-4, l...@temple.edu wrote:
>
> *I had a 4.9.78-ti-r94 kernel, and I used the update_kernel script to 
> update the kernel to* *4.9.89-bone10. However, when I run "run_test_motor 
> -f", I still get an error as:*
>
> ERROR: pru-rproc driver missing
>
>
> Please let me know how I should fix this. Thanks.
>

Robotics Cape library works with the PRU remoteproc driver, not PRU UIO 
driver. Go back to the -ti kernel and enable the RPROC driver overlay.
 

>
> Li Bai
>
> On Monday, October 23, 2017 at 10:23:11 AM UTC-4, simo zz wrote:
>>
>> Hello Robert,
>>
>> Thank you very much. It works now. :)
>>
>> Regards,
>> Simon
>>
>> On Mon, Oct 23, 2017 at 4:10 PM, Robert Nelson  
>> wrote:
>>
>>> On Mon, Oct 23, 2017 at 3:59 AM, simo zz  wrote:
>>> > Hello,
>>> >
>>> > I am trying to communicate with the PRU unit on a Debian 9.2 and kernel
>>> > 4.9.54-ti-r68 by Robert Nelson, but the file
>>>
>>> 4.9.x-ti-ry is remoteproc pruss only..
>>>
>>> Use the 4.9.x-bone kernel
>>>
>>> cd /opt/scripts/tools/
>>> git pull
>>> sudo ./update_kernel.sh --bone-kernel --lts-4_9
>>>
>>> and make sure you set the uio overlay:
>>>
>>> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options
>>>
>>> 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/48defeb5-c667-4a97-a1a6-f628b6837f0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Rolling back Debian image from 8.3 2016-01-24 to 7.8 2015-03-01

[Robert Nelson]

On Wed, Apr 11, 2018 at 5:18 PM, Bobbi N Sean Donovan
 wrote:
> Robert, thank you so much for the reply.  I followed your link below on the
> doc on how to fix the image and I get the following error +Failed dependency
> check.  I am trying to do this to the SDCard that the BBB booted from.
>
> Any further suggestions?


> debian@beaglebone:/yakbuild$ sudo ./build_kernel.sh
> + Detected build host [Debian GNU/Linux 7.8 (wheezy)]
> + host: [armv7l]
> + git HEAD commit: [cf96eadcdf82479e00e2f33ed4c8141ac904bbf6]
> Debian/Ubuntu/Mint: missing dependencies, please install:
> -
> sudo apt-get update
> sudo apt-get install bc lzma lzop libncurses5-dev libcurl4-gnutls-dev
> libelf-dev

It's giving you directions to do right here ^.

The rerun ./build_kernel.sh

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

Re: [beagleboard] Debian jessie (4.4.113-ti-r148) boots to rescue mode when cape attached (u-boot 2018.03+rootwait 1?)

[smith . winston . 101]

On Sunday, April 8, 2018 at 1:03:57 PM UTC-4, RobertCNelson wrote:

> Ah, you found a fun bug in the old path..  I'll fix it up for the next 
> person, but you can go down the new path with your setup... 
>
> [snip...]
>
> in /boot/uEnv.txt 
>
> remove your: dtb=am335x-boneblack-emmc-overlay.dtb 
>
> Then set: 
>
> enable_uboot_overlays=1 
> disable_uboot_overlay_video=1 
>

Making this change solved it.  I updated my bb_ble_image.sh script to add 
--enable-uboot-cape-overlays and move from --dtb beaglebone-nohdmi to --dtb 
beagblebone.  However, I couldn't see a way when invoking setup_sdcard.sh 
to set disable_uboot_overlay_video=1 in uEnv.txt via the command line.  So 
I made the following change to add a custom --disable-uboot-overlay-video 
option to setup_sdcard.sh (which temporarily helps me out in this case!):

diff --git a/tools/setup_sdcard.sh b/tools/setup_sdcard.sh
index 9d86f92..b9de76e 100755
--- a/tools/setup_sdcard.sh
+++ b/tools/setup_sdcard.sh
@@ -1266,7 +1266,11 @@ populate_rootfs () {
echo "###" >> ${wfile}
echo "###Disable auto loading of virtual capes 
(emmc/video/wireless/adc)" >> ${wfile}
echo "#disable_uboot_overlay_emmc=1" >> ${wfile}
-   echo "#disable_uboot_overlay_video=1" >> ${wfile}
+   if [ "x${uboot_overlay_video}" = "xdisable" ] ; then
+   echo "disable_uboot_overlay_video=1" >> 
${wfile}
+   else
+   echo "#disable_uboot_overlay_video=1" >> 
${wfile}
+   fi
echo "#disable_uboot_overlay_audio=1" >> ${wfile}
echo "#disable_uboot_overlay_wireless=1" >> ${wfile}
echo "disable_uboot_overlay_adc=1" >> ${wfile}
@@ -2041,6 +2045,9 @@ while [ ! -z "$1" ] ; do
--enable-uboot-pru-rproc-414ti)
uboot_pru_rproc_414ti="enable"
;;
+   --disable-uboot-overlay-video)
+   uboot_overlay_video="disable"
+   ;;
--efi)
uboot_efi_mode="enable"
;;

With this I now have an eMMC flasher image that creates the correct 
/boot/uEnv.txt after flashing.

Please let me know if there is a better way to disable video (I just need a 
cmd line option vs whitelisting), there are other options that you might 
want to control (e.g. audio, adc etc) so maybe a more generalized version 
of this would be a nice enhancement.

Many thanks!


-W
 

-- 
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/d3c65884-36b9-4611-8796-cacdf69683af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Can't see patch pins in pingroup

[adrianpeniak]

Hello all,

I trying patch file *am335x-boneblack.dts* 
(http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.4.y/arch/arm/boot/dts/am335x-boneblack.dts)
 
in yocto in order to using *pru* on my BBB. However I can't see any change 
in */sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups. *Pin groups looks 
like (still same):
































*root@beaglebone:~# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups 
registeredpin groups: group:pinmux_clkout2_pinpin 109 
(44e109b4.0)group: pinmux_uart0_pinspin 92 (44e10970.0)pin 93 
(44e10974.0)group: cpsw_defaultpin 68 (44e10910.0)pin 69 
(44e10914.0)pin 70 (44e10918.0)pin 71 (44e1091c.0)pin 72 
(44e10920.0)pin 73 (44e10924.0)pin 74 (44e10928.0)pin 75 
(44e1092c.0)pin 76 (44e10930.0)pin 77 (44e10934.0)pin 78 
(44e10938.0)pin 79 (44e1093c.0)pin 80 (44e10940.0)group: 
cpsw_sleeppin 68 (44e10910.0)pin 69 (44e10914.0)pin 70 
(44e10918.0)pin 71 (44e1091c.0)pin 72 (44e10920.0)pin 73 
(44e10924.0)pin 74 (44e10928.0)pin 75 (44e1092c.0)pin 76 
(44e10930.0)pin 77 (44e10934.0)pin 78 (44e10938.0)pin 79 
(44e1093c.0)pin 80 (44e10940.0)group: davinci_mdio_defaultpin 82 
(44e10948.0)pin 83 (44e1094c.0)group: davinci_mdio_sleeppin 82 
(44e10948.0)pin 83 (44e1094c.0)group: pinmux_mmc1_pinspin 88 
(44e10960.0)group: pinmux_emmc_pinspin 32 (44e10880.0)pin 33 
(44e10884.0)pin 0 (44e10800.0)pin 1 (44e10804.0)pin 2 
(44e10808.0)pin 3 (44e1080c.0)pin 4 (44e10810.0)pin 5 
(44e10814.0)pin 6 (44e10818.0)pin 7 (44e1081c.0)group: 
user_leds_defaultpin 21 (44e10854.0)pin 22 (44e10858.0)pin 23 
(44e1085c.0)pin 24 (44e10860.0)group: user_leds_sleeppin 21 
(44e10854.0)pin 22 (44e10858.0)pin 23 (44e1085c.0)pin 24 
(44e10860.0)group: mcasp0_pinspin 107 (44e109ac.0)pin 103 
(44e1099c.0)pin 101 (44e10994.0)pin 100 (44e10990.0)pin 27 
(44e1086c.0)group:pinmux_i2c0_pinspin 98 (44e10988.0)pin 99 
(44e1098c.0)group: nxp_hdmi_bonelt_pinspin 108 (44e109b0.0)pin 40 
(44e108a0.0)pin 41 (44e108a4.0)pin 42 (44e108a8.0)pin 43 
(44e108ac.0)pin 44 (44e108b0.0)pin 45 (44e108b4.0)pin 46 
(44e108b8.0)pin 47 (44e108bc.0)pin 48 (44e108c0.0)pin 49 
(44e108c4.0)pin 50 (44e108c8.0)pin 51 (44e108cc.0)pin 52 
(44e108d0.0)pin 53 (44e108d4.0)pin 54 (44e108d8.0)pin 55 
(44e108dc.0)pin 56 (44e108e0.0)pin 57 (44e108e4.0)pin 58 
(44e108e8.0)pin 59 (44e108ec.0) group: nxp_hdmi_bonelt_off_pinspin 108 
(44e109b0.0)group: pinmux_i2c2_pinspin 94 (44e10978.0)pin 95 
(44e1097c.0)*

However tree in */sys/devices/platform/ocp/* looks as I expected (reflect 
patch):







*root@beaglebone:~# ls 
/sys/devices/platform/ocp/4030.ocmcram   
4740.usb   4804c000.gpio  
481d8000.mmc   49a0.tptc  
driver_override
ocp:l4_wkup@44c040302000.ocmcram_nocache   
48038000.mcasp 4806.mmc   
4820.interrupt-controller  4a10.ethernet  
modalias   of_node44e07000.gpio  
48042000.timer 480c8000.mailbox   
4830e000.lcdc  4a30.pruss 
ocp:P9_24_pinmux   power44e09000.serial
48044000.timer 480ca000.spinlock  
4831.rng   4c00.emif  
ocp:P9_26_pinmux   subsystem44e0b000.i2c   
48046000.timer 4819c000.i2c   
4900.edma  5310.sham  
ocp:P9_27_pinmux   uevent44e35000.wdt   
48048000.timer 481ac000.gpio  
4980.tptc  5350.aes   
ocp:P9_30_pinmux44e3e000.rtc   
4804a000.timer 481ae000.gpio  
4990.tptc  5600.sgx   
ocp:cape-universal*

My patch is currently following:












































































































*--- ./arch/arm/boot/dts/am33xx.dtsi+++ ./arch/arm/boot/dts/am33xx.dtsi@@ 
-165,7 +165,7 @@  * for the moment, just use a fake OCP bus entry to 
represent  * the whole bus hierarchy.  */-ocp: ocp {+ocp 
{ compatible = "simple-bus"; #address-cells = <1>; 
#size-cells = <1>;--- ./arch/arm/boot/dts/am335x-boneblack.dts+++ 
./arch/arm/boot/dts/am335x-boneblack.dts@@ -86,6 +86,83 @@ 
AM33XX_IOPAD(0x86c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a11.GPIO1_27 
*/ >; };++P9_24_default_pin: pinmux_P9_24_default_pin { 
pinctrl-single,pins = <+AM33XX_IOPAD(0x0984, 

Re: [beagleboard] Rolling back Debian image from 8.3 2016-01-24 to 7.8 2015-03-01

[Bobbi N Sean Donovan]

Robert, thank you so much for the reply.  I followed your link below on the 
doc on how to fix the image and I get the following error *+Failed 
dependency check*.  I am trying to do this to the SDCard that the BBB 
booted from.

Any further suggestions?

Here is a copy of the Putty Dump
debian@beaglebone:/$ sudo git clone 
https://github.com/RobertCNelson/yakbuild   
   
Cloning into 'yakbuild'...
remote: Counting objects: 343, done. [K
remote: Compressing objects:  20% (1/5)[K
remote: Compressing objects:  40% (2/5)[K
remote: Compressing objects:  60% (3/5)[K
remote: Compressing objects:  80% (4/5)[K
remote: Compressing objects: 100% (5/5)[K
remote: Compressing objects: 100% (5/5), done. [K
Receiving objects:   0% (1/343)   
Receiving objects:   1% (4/343)   
Receiving objects:   2% (7/343)   
Receiving objects:   3% (11/343)   
Receiving objects:   4% (14/343)   
Receiving objects:   5% (18/343)   
Receiving objects:   6% (21/343)   
Receiving objects:   7% (25/343)   
Receiving objects:   8% (28/343)   
Receiving objects:   9% (31/343)   
Receiving objects:  10% (35/343)   
Receiving objects:  11% (38/343)   
Receiving objects:  12% (42/343)   
Receiving objects:  13% (45/343)   
Receiving objects:  14% (49/343)   
Receiving objects:  15% (52/343)   
Receiving objects:  16% (55/343)   
Receiving objects:  17% (59/343)   
Receiving objects:  18% (62/343)   
Receiving objects:  19% (66/343)   
Receiving objects:  20% (69/343)   
Receiving objects:  21% (73/343)   
Receiving objects:  22% (76/343)   
Receiving objects:  23% (79/343)   
Receiving objects:  24% (83/343)   
Receiving objects:  25% (86/343)   
Receiving objects:  26% (90/343)   
Receiving objects:  27% (93/343)   
Receiving objects:  28% (97/343)   
Receiving objects:  29% (100/343)   
Receiving objects:  30% (103/343)   
Receiving objects:  31% (107/343)   
Receiving objects:  32% (110/343)   
Receiving objects:  33% (114/343)   
Receiving objects:  34% (117/343)   
Receiving objects:  35% (121/343)   
Receiving objects:  36% (124/343)   
Receiving objects:  37% (127/343)   
Receiving objects:  38% (131/343)   
Receiving objects:  39% (134/343)   
Receiving objects:  40% (138/343)   
Receiving objects:  41% (141/343)   
Receiving objects:  42% (145/343)   
Receiving objects:  43% (148/343)   
Receiving objects:  44% (151/343)   
Receiving objects:  45% (155/343)   
Receiving objects:  46% (158/343)   
Receiving objects:  47% (162/343)   
Receiving objects:  48% (165/343)   
Receiving objects:  49% (169/343)   
Receiving objects:  50% (172/343)   
Receiving objects:  51% (175/343)   
Receiving objects:  52% (179/343)   
Receiving objects:  53% (182/343)   
Receiving objects:  54% (186/343)   
Receiving objects:  55% (189/343)   
Receiving objects:  56% (193/343)   
Receiving objects:  57% (196/343)   
Receiving objects:  58% (199/343)   
Receiving objects:  59% (203/343)   
Receiving objects:  60% (206/343)   
Receiving objects:  61% (210/343)   
Receiving objects:  62% (213/343)   
Receiving objects:  63% (217/343)   
Receiving objects:  64% (220/343)   
Receiving objects:  65% (223/343)   
Receiving objects:  66% (227/343)   
Receiving objects:  67% (230/343)   
Receiving objects:  68% (234/343)   
Receiving objects:  69% (237/343)   
Receiving objects:  70% (241/343)   
Receiving objects:  71% (244/343)   
Receiving objects:  72% (247/343)   
Receiving objects:  73% (251/343)   
Receiving objects:  74% (254/343)   
Receiving objects:  75% (258/343)   
Receiving objects:  76% (261/343)   
Receiving objects:  77% (265/343)   
Receiving objects:  78% (268/343)   
Receiving objects:  79% (271/343)   
Receiving objects:  80% (275/343)   
Receiving objects:  81% (278/343)   
Receiving objects:  82% (282/343)   
Receiving objects:  83% (285/343)   
Receiving objects:  84% (289/343)   
Receiving objects:  85% (292/343)   
Receiving objects:  86% (295/343)   
Receiving objects:  87% (299/343)   
Receiving objects:  88% (302/343)   
Receiving objects:  89% (306/343)   
Receiving objects:  90% (309/343)   
Receiving objects:  91% (313/343)   
Receiving objects:  92% (316/343)   
Receiving objects:  93% (319/343)   
Receiving objects:  94% (323/343)   
Receiving objects:  95% (326/343)   
Receiving objects:  96% (330/343)   
Receiving objects:  97% (333/343)   
Receiving objects:  98% (337/343)   
Receiving objects:  99% (340/343)   
Receiving objects: 100% (343/343)   
Receiving objects: 100% (343/343), 61.60 KiB, done.
remote: Total 343 (delta 3), reused 3 (delta 2), pack-reused 336 [K
Resolving deltas:  12% (35/274)   
Resolving deltas:  15% (43/274)   
Resolving deltas:  16% (44/274)   
Resolving deltas:  29% (80/274)   
Resolving deltas:  32% (89/274)   
Resolving deltas:  35% (98/274)   
Resolving deltas:  41% (115/274)   
Resolving deltas:  42% (117/274)   
Resolving deltas:  43% (120/274)   
Resolving deltas:  44% (122/274)   
Resolving deltas:  45% (124/274)   
Resolving 

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> On Apr 11, 2018, at 6:04 AM, pierrick.ra...@gadz.org wrote:
> 
> Hi John, 
> Thanks for the help, I looked into the iio_generic_buffer.c example and i 
> patched it to disable the hardware triggers thanks to the patch presented on 
> this page : https://www.teachmemicro.com/beaglebone-black-adc/ 
>  I am now able to reader 
> a buffer from the different channel. 
> However I have 2 majors questions that remains:
> 
> 1) I only want to use on channel, then I do not want the ADC to sample the 
> other one so that i'll have the maximum sampling rate. What is the best way 
> to disable the channel? If I do not enable them in iio_generic_buffer.c I am 
> not sure that the ADC is not going to sample this channel or not (well, I 
> think it wont sample but I prefer to be sure). Is it preferable to not 
> mention them on the devicetree so that Linux wont know that there are 
> multiple channels on the ADC? This part is not very clear for me. 
> 
> 2) To change the sample frequency of the ADC you mentioned that it is done 
> using the device tree however I did not find any argument on the ADC 
> devicetree to change the sampling frequency. I read the discussion you had on 
> this post (https://patchwork.kernel.org/patch/9391487/ 
>  ) but it is not clear if the 
> frequency setting is done using the kernel module or devicetrees. Could you 
> explain me this please? 
Looking at this a little more, there is a mistake in the ADC DT file 
BB-ADC-0A00.dts. The maximum averaging is 16, not 0x16.

The line
ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16 0x16>

should be changed to
ti,chan-step-avg = <16 16 16 16 16 16 16 16>
Fortunately, the driver does a range check and sets the value to 16. 

ti,chan-step-avg = <1 1 1 1 1 1 1 1> /* 2 sample average */
ti,chan-step-opendelay = <0 0 0 0 0 0 0 0>
ti,chan-step-sampledelay = <0 0 0 0 0 0 0 0>

To achieve a conversion rate of 800 KS/s

>From ti_am335x_tscad.c, 1 + (1 + 13) * 2 = 30 cycles

The ADC uses a 24 MHz clock, so 1/24,000,000 * 15 = 800 KS/s

You could increase the sampling rate to 1.6MS/s by changing the average to 0, 
which means there is no averaging. To achieve this, the minimum number of 
cycles for a conversion is 15 (12.3.7 of the AM3358 Technical Reference Manual)

1 + (1 + 13) * 1 = 15 cycles

which will give you 1.6 MS/s

Regards,
John

> 
> Thanks a lot 
> 
> Pierrick 
> 
> Le mercredi 28 mars 2018 00:45:01 UTC-4, john3909 a écrit :
> Look at the kernel source under tools/iio for examples on how to use IIO.
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Mar 27, 2018, at 12:10 PM, pierric...@gadz.org <> wrote:
>> 
>> Hi John, 
>> 
>> Sorry for the late answer, I had hard time using the PRUs and I am now going 
>> to use the IIO ADC driver, I am able to read the sample with the cat command 
>> in /sys/bus/iio/devices/iio:device0/in_voltage3_raw 
>> However I am not able to use Libiio in order to read data from a user space 
>> application, I am reading (nil) instead of my data. Do you have any idea of 
>> where does the problem comes from ? 
>> 
>> Here is the code I am using in the user space :
>> 
>> 
>> #define _BSD_SOURCE
>> #define _GNU_SOURCE
>> #define _DEFAULT_SOURCE
>> 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> 
>> #ifdef __APPLE__
>> #include 
>> #else
>> #include 
>> #endif
>> 
>> struct iio_context *ctx;
>> struct iio_device *dev;
>> struct iio_channel *ch;
>> 
>> int main()
>> {
>>   ctx = iio_create_default_context();
>>   dev = iio_context_get_device(ctx, 0);
>>   ch = iio_device_get_channel(dev, 3);
>> 
>> 
>>   iio_device_attr_write_longlong(dev, "sample_rate", 100);
>>   iio_channel_attr_write_double(ch, "scale", 1);
>> 
>>   iio_channel_enable(ch);
>> 
>>   char *a = iio_device_get_data(dev);
>>   printf("%p\n", a);
>> 
>>   iio_channel_disable(ch);
>> 
>>   return 0;
>> }
>> 
>> Thanks 
>> 
>> Pierrick 
>> 
>> 
>> Le lundi 26 février 2018 16:46:11 UTC-5, john3909 a écrit :
>> The IIO ADC driver can run at 800K samples per second. Here is the patch 
>> that made that possible. 
>> 
>> https://patchwork.kernel.org/patch/9391487/ 
>> 
>> 
>> I can confirm that I have tested the driver at 800Ksps and it works fine as 
>> long as you have a proper low impedance source for each ADC channel. CPU 
>> utilization was about 5% if I recall and that was probably used by the iiod 
>> daemon, which I used to display the waveform on a remote Linux app. 
>> 
>> There is example code in the original Starterware for McSPI, which should 
>> work fine if you are using the PRU low level drivers. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 26, 2018, at 12:56 PM, pierric...@gadz.org <> wrote:
>>> 
>>> Thanks John, 
>>> 
>>> I am now working with the starterware_PRU but i did not find examples for 
>>> using the McSPI with the PRU, do you think 

Re: [beagleboard] sysfs gpio deprecated?

[Drew Fustini]

The sysfs gpio ABI will be removed from the Linux kernel in 2020.  The new
ABI uses a character device to represent each gpiochip.

libgpiod started by Bartosz Golaszewski is a good way for userspace code to
use the the new ABI:
https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/

Regards,
Drew

On Wed, Apr 11, 2018, 2:51 PM Fred Kerr  wrote:

> Hi, I've started looking at the sysfs gpio interface and saw some notes
> that it's considered obsolete and deprecated. I'm looking for a good
> pointer to the ABI (?) character driver interface for gpio. I'll probably
> find one right after posting this. :)
>
> In case I'm not using the right terminology, the sysfs interface is where
> you go to /sys/class/gpio and echo ## > export to get gpio pins exported
> that you can then interact with?
>
> Thanks,
> Fred
>
> --
> 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/14e918b7-c514-4412-85a6-73b0d5f576bf%40googlegroups.com
> 
> .
> 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/CAEf4M_CHaUPcEzunLmomV%3DNoy0H8qBvQV9znJ5mnJqzDxetzQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] sysfs gpio deprecated?

[Fred Kerr]

Hi, I've started looking at the sysfs gpio interface and saw some notes 
that it's considered obsolete and deprecated. I'm looking for a good 
pointer to the ABI (?) character driver interface for gpio. I'll probably 
find one right after posting this. :)

In case I'm not using the right terminology, the sysfs interface is where 
you go to /sys/class/gpio and echo ## > export to get gpio pins exported 
that you can then interact with?

Thanks,
Fred

-- 
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/14e918b7-c514-4412-85a6-73b0d5f576bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[John Syne]

> On Apr 11, 2018, at 6:04 AM, pierrick.ra...@gadz.org wrote:
> 
> Hi John, 
> Thanks for the help, I looked into the iio_generic_buffer.c example and i 
> patched it to disable the hardware triggers thanks to the patch presented on 
> this page : https://www.teachmemicro.com/beaglebone-black-adc/ 
>  I am now able to reader 
> a buffer from the different channel. 
> However I have 2 majors questions that remains:
> 
> 1) I only want to use on channel, then I do not want the ADC to sample the 
> other one so that i'll have the maximum sampling rate. What is the best way 
> to disable the channel? If I do not enable them in iio_generic_buffer.c I am 
> not sure that the ADC is not going to sample this channel or not (well, I 
> think it wont sample but I prefer to be sure). Is it preferable to not 
> mention them on the devicetree so that Linux wont know that there are 
> multiple channels on the ADC? This part is not very clear for me. 
First, you have to enable each channel for it to be placed in the buffer. 
Second, you have to setup the size of the buffer and then enable the buffer to 
start filling the buffer with samples. When you enable the buffer, 
tiadc_buffer_postenable() is run which only scans those channels you enabled.
> 
> 2) To change the sample frequency of the ADC you mentioned that it is done 
> using the device tree however I did not find any argument on the ADC 
> devicetree to change the sampling frequency. I read the discussion you had on 
> this post (https://patchwork.kernel.org/patch/9391487/ 
>  ) but it is not clear if the 
> frequency setting is done using the kernel module or devicetrees. Could you 
> explain me this please? 
The sampling frequency is dependent on the Open Delay, Sample Delay and 
Conversion Time. If you look at the file linux/mfd/ti_am335x_tscadc.h line 145, 
there is an explanation of this.

Regards,
John
> 
> Thanks a lot 
> 
> Pierrick 
> 
> Le mercredi 28 mars 2018 00:45:01 UTC-4, john3909 a écrit :
> Look at the kernel source under tools/iio for examples on how to use IIO.
> 
> Regards,
> John
> 
> 
> 
> 
> 
>> On Mar 27, 2018, at 12:10 PM, pierric...@gadz.org  wrote:
>> 
>> Hi John, 
>> 
>> Sorry for the late answer, I had hard time using the PRUs and I am now going 
>> to use the IIO ADC driver, I am able to read the sample with the cat command 
>> in /sys/bus/iio/devices/iio:device0/in_voltage3_raw 
>> However I am not able to use Libiio in order to read data from a user space 
>> application, I am reading (nil) instead of my data. Do you have any idea of 
>> where does the problem comes from ? 
>> 
>> Here is the code I am using in the user space :
>> 
>> 
>> #define _BSD_SOURCE
>> #define _GNU_SOURCE
>> #define _DEFAULT_SOURCE
>> 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> 
>> #ifdef __APPLE__
>> #include 
>> #else
>> #include 
>> #endif
>> 
>> struct iio_context *ctx;
>> struct iio_device *dev;
>> struct iio_channel *ch;
>> 
>> int main()
>> {
>>   ctx = iio_create_default_context();
>>   dev = iio_context_get_device(ctx, 0);
>>   ch = iio_device_get_channel(dev, 3);
>> 
>> 
>>   iio_device_attr_write_longlong(dev, "sample_rate", 100);
>>   iio_channel_attr_write_double(ch, "scale", 1);
>> 
>>   iio_channel_enable(ch);
>> 
>>   char *a = iio_device_get_data(dev);
>>   printf("%p\n", a);
>> 
>>   iio_channel_disable(ch);
>> 
>>   return 0;
>> }
>> 
>> Thanks 
>> 
>> Pierrick 
>> 
>> 
>> Le lundi 26 février 2018 16:46:11 UTC-5, john3909 a écrit :
>> The IIO ADC driver can run at 800K samples per second. Here is the patch 
>> that made that possible. 
>> 
>> https://patchwork.kernel.org/patch/9391487/ 
>> 
>> 
>> I can confirm that I have tested the driver at 800Ksps and it works fine as 
>> long as you have a proper low impedance source for each ADC channel. CPU 
>> utilization was about 5% if I recall and that was probably used by the iiod 
>> daemon, which I used to display the waveform on a remote Linux app. 
>> 
>> There is example code in the original Starterware for McSPI, which should 
>> work fine if you are using the PRU low level drivers. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 26, 2018, at 12:56 PM, pierric...@gadz.org <> wrote:
>>> 
>>> Thanks John, 
>>> 
>>> I am now working with the starterware_PRU but i did not find examples for 
>>> using the McSPI with the PRU, do you think it will be hard to adapt the 
>>> initial code to the PRU ? 
>>> By the way, looking to the IIO driver documentation, it seems that for the 
>>> AM335x chip the max sampling rate is only 200k samples per second which may 
>>> not be enough :
>>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide 
>>>  ; am I 
>>> right ? 
>>> 
>>> 
>>> Thanks 
>>> 
>>> Pierrick 
>>> 

Re: [beagleboard] Rolling back Debian image from 8.3 2016-01-24 to 7.8 2015-03-01

[Robert Nelson]

On Wed, Apr 11, 2018 at 1:41 PM,   wrote:
> I am trying to rollback the Debian image on my Beaglebone Black Rev C
> (Embest) from the image that shipped on it on the board Debian 8.3 Image
> 2016-01-24 kernel 4.1.15-ti-rt-43 to Debian 7.8 image 2015-03-01 kernel
> 3.8.13-bone70 .  I downloaded both files from
> https://beagleboard.org/latest-images.  I put the older image on an SD Card
> using Win32DiskImager.  I then install the SD card in the BBB and make the
> single change to the uEnv.txt file to remove the "#" from the final line
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh to make the SD
> card a flasher image.  I power cycle the BBB and it begins to boot again of
> the SD Card. When I do this I get the following error:
>
> Begin: Running /scripts/init-bottom ... done.
> Starting eMMC Flasher
> -
> Checking for Valid BBB EEPROM header
> Valid BBB EEPROM header found
> -
> copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
> lsblk:
> NAMEMAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> mmcblk0 179:00   7.4G  0 disk
> |-mmcblk0p1 179:1096M  0 part /boot/uboot
> `-mmcblk0p2 179:20   3.5G  0 part /
> -
> df -h | grep rootfs:
> rootfs  3.5G  1.8G  1.6G  54% /
> -
> Error: [/dev/mmcblk1] does not exist
> writing to [/dev/mmcblk1] failed
>
> I am powered off a 5A, 5V DC supply and I never peak above 300 mA.
>
> So to make sure my process is okay, I tried going from the Debian 8.3
> 2016-01-24 to the Debian 8.6 2016-11-06 4GB SD LXQT image.  This worked fine
> and the 8.6 ran on the eMMC.  I then rolled back to the 8.3 image with no
> issues.  So I think my process is okay.
>
> It appears to be an issue with mounting of the eMMC "drive"
>
> Any help or advice would be greatly appreciated.

This issue was fixed with 3.8.13-bone80, which was released on: Jun 15, 2016

It's a hardware issue, your board has eMMC 5.1 or newer eMMC...

Here are the two patches:

https://github.com/RobertCNelson/bb-kernel/commit/bd5a1f38c99bbe712d21c1e145b0c660dca9dee7

Doc's on how to fix it for your image:

https://gist.github.com/RobertCNelson/39faf80ddc9fcefae74dce2c6ca2eb45

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/CAOCHtYgtTy%3DB9stYFPwxabR3RnYZ8%2BEAWs%3DBYDNT%3DSVKnBMPwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Rolling back Debian image from 8.3 2016-01-24 to 7.8 2015-03-01

[bsdonovan]

I am trying to rollback the Debian image on my Beaglebone Black Rev C 
(Embest) from the image that shipped on it on the board* Debian 8.3 Image 
2016-01-24 kernel 4.1.15-ti-rt-43* to *Debian 7.8 image 2015-03-01 kernel 
3.8.13-bone70* .  I downloaded both files from 
https://beagleboard.org/latest-images.  I put the older image on an SD Card 
using Win32DiskImager.  I then install the SD card in the BBB and make the 
single change to the *uEnv.txt* file to remove the "#" from the final line 
*#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh* to make the 
SD card a flasher image.  I power cycle the BBB and it begins to boot again 
of the SD Card. When I do this I get the following error:

Begin: Running /scripts/init-bottom ... done.
Starting eMMC Flasher
-
Checking for Valid BBB EEPROM header
Valid BBB EEPROM header found
-
copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
lsblk:
NAMEMAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0 179:00   7.4G  0 disk 
|-mmcblk0p1 179:1096M  0 part /boot/uboot
`-mmcblk0p2 179:20   3.5G  0 part /
-
df -h | grep rootfs:
rootfs  3.5G  1.8G  1.6G  54% /
-
Error: [/dev/mmcblk1] does not exist
writing to [/dev/mmcblk1] failed

I am powered off a 5A, 5V DC supply and I never peak above 300 mA.  

So to make sure my process is okay, I tried going from the *Debian 8.3 
2016-01-24 *to the *Debian 8.6 2016-11-06 4GB SD LXQT *image.  This worked 
fine and the 8.6 ran on the eMMC.  I then rolled back to the 8.3 image with 
no issues.  So I think my process is okay.

It appears to be an issue with mounting of the eMMC "drive"

Any help or advice would be greatly appreciated.

Sean D.

Below are the uEnv.txt file and the actual boot with failure from the SD 
Card with the 7.8 flasher image on it.  


The following is my Debian 7.8 image uEnv.txt file as setup to be the 
flasher:

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=3.8.13-bone70
#dtb=
cmdline=quiet init=/lib/systemd/systemd 

##Example
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Disable HDMI/eMMC
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

##Disable HDMI
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

##Disable eMMC
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G

##Audio Cape (needs HDMI Audio disabled)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02


##enable BBB: eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
===

Here is the entire boot sequence with failure:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.04.10 12:20:51 
=~=~=~=~=~=~=~=~=~=~=~=
  
U-Boot SPL 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31)
Trying to boot from MMC
bad magic



U-Boot 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build: 
jenkins-github_Bootloader-Builder-313


   Watchdog enabled

I2C:   ready

DRAM:  512 MiB

Reset Source: Power-on reset has occurred.

MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

Using default environment


Net:not set. Validating first E-fuse MAC

cpsw, usb_ether

Press SPACE to abort autoboot in 2 seconds

switch to partitions #0, OK

mmc0 is current device

Scanning mmc 0:1...

gpio: pin 56 (gpio 56) value is 0

gpio: pin 55 (gpio 55) value is 0

gpio: pin 54 (gpio 54) value is 0

gpio: pin 53 (gpio 53) value is 1

switch to partitions #0, OK

mmc0 is current device

gpio: pin 54 (gpio 54) value is 1

Checking for: /uEnv.txt ...

reading uEnv.txt

933 bytes read in 4 ms (227.5 KiB/s)

gpio: pin 55 (gpio 55) value is 1

Loaded environment from uEnv.txt

Importing environment from mmc ...

Checking if uenvcmd is set ...

gpio: pin 56 (gpio 56) value is 1

Running uenvcmd ...

775 bytes read in 40 ms (18.6 KiB/s)

5617184 bytes read in 340 ms (15.8 MiB/s)

2867606 bytes read in 192 ms (14.2 MiB/s)

26098 bytes read in 64 ms (397.5 KiB/s)

Kernel image @ 0x8200 [ 0x00 - 0x55b620 ]

## Flattened Device Tree blob at 8800

   Booting using the fdt blob at 0x8800

   Using Device Tree in place at 8800, end 880095f1


Starting kernel ...


Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) 
(gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
cr=50c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 

[beagleboard] support for android 6 on BBB Wireless board

[amitnagal18]

 Hi 

I Want to build android (6 or 7) for BBB wireless board.bo
can somebody suggest me from where to download source and build 
instructions for BBB wireless board

regards
amit

-- 
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/c2380d5a-ed30-446d-b7fd-82c81b4d1b0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Android Support for Beagleboard black wireless board

[amitnagal18]

  Hi 

  i want to build android (6 or 7) for Beagleboard black wireless board . 
  can somebody guide me from where to download AOSP source for this board 
and the build steps .
  
  i asked this because of below 2 reasons ::
  a) On beagleboard website , it is mentioned 3rd party support for android 
. but i could not find  any information regarding download of 3rd party 
android source code and build .
  b) On this forum , in discussions , it is suggested to refer to 
http://www.2net.co.uk/android4beagle.html . 
  however board support matrix shows BBB . is BBB wireless board also 
supported ? will BBB images work with BBB wireless board also ?

  Regards
  Amit Nagal

-- 
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/b72227dd-7c8e-4169-9333-df31e4f51448%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] USB-Ethernet Adapter Test

[João Venâncio Abreu Santos Filho]

I would like to test a concept with the Beaglebone Black configured with 
the PREEMPT-RT patch.

An application would use the native Ethernet port and an USB-Ethernet 
adapter to roundtrip transactions in an Ethernet based protocol. My goal is 
to develop ou use a test application to imply the perfomance of the USB 
adapter on UDP and/or TCP cyclic packet transfer, executing a cyclictest at 
the same time. I'm not sure about the best tools and layouts to perform 
this test.

Do you have any idea of the best tools or reference a article/book to 
perform embedded linux Ethernet tests. Could you reccomend any a specific 
tool?

-- 
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/5cb67f85-3fc6-4b68-83ae-8e751fe903ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleLogic logic analyzer on PocketBeagle

[Randy Rossi]

Thanks for the info.  That explains a lot.  However, I see in the system 
reference manual for the pocket there are eight pr1_pru1_pru_r31_xxx pins.  
Any idea why only 4 were working in my test?   Sounds like PRU1 should be 
able to see 8.

https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#67_PRUICSS


On Wednesday, April 11, 2018 at 12:25:40 PM UTC-4, Kumar Abhishek wrote:
>
> All,
>
> BeagleLogic, the software, will run on the PocketBeagle for sure, but the 
> pins will be limited as only a very limited number of PRU1 pins (the pins 
> marked pr1_pru_r31_xx) are broken out on the expansion headers. The way 
> BeagleLogic works is that PRU1 samples the pins while PRU0 writes samples 
> to RAM. Therefore the R31 of the PRU1 is the one it can read. Theoretically 
> if one can tweak the firmware and the kernel driver, one could get it to 
> sample the PRU0 pins instead, so you could have the PRU0 pins available.
>
> I have designed a board prototype that converts the BeagleLogic to a 
> standalone logic analyzer - 
> https://theembeddedkitchen.net/announcing-beaglelogic-standalone/694 but 
> is not released *yet*, although I do hope to make it available for sale in 
> the near future. There's a link you can sign up to on the blog page, and 
> I'll send you updates as and when it happens.
>
> Thanks
> Kumar Abhishek
>
> On Wednesday, April 11, 2018 at 5:45:03 AM UTC+5:30, v37...@gmail.com 
> wrote:
>>
>> Hello,
>>
>> did you make any progress or anything to share?  I use the beagle-logic 
>> on the BBB, but it could be interesting on the PB too.  Any website/blog or 
>> git?
>>
>> cheers
>>
>>
>>
>> On Saturday, April 7, 2018 at 1:32:58 AM UTC+2, Randy Rossi wrote:
>>
>>> I recently got the BeagleLogic logic analyzer (
>>> https://github.com/abhishek-kakkar/BeagleLogic) running on the 
>>> PocketBeagle under a linux 4.9 kernel.  It pretty much works as-is.  
>>> However, only 4 of the 20 pins that can be configured as pruin produce any 
>>> results.   My (limited) understanding is that the black and pocket 
>>> processors are the same (AM335x) so I would have expected R31 in the 
>>> assembly code to be able to read all pins.  Anyone have experience with 
>>> getting the PRUs on the Pocket to read pins other than {p1_2, p1_4, p1_35, 
>>> p2_35}?  All my pins were configured as pruin when I was testing.  Maybe 
>>> some mapping that is different between the Pocket & Black? 
>>>
>>>
>>>

-- 
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/8425d149-6df5-4099-8d44-41c6aadf9dcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleLogic logic analyzer on PocketBeagle

[Kumar Abhishek]

All,

BeagleLogic, the software, will run on the PocketBeagle for sure, but the 
pins will be limited as only a very limited number of PRU1 pins (the pins 
marked pr1_pru_r31_xx) are broken out on the expansion headers. The way 
BeagleLogic works is that PRU1 samples the pins while PRU0 writes samples 
to RAM. Therefore the R31 of the PRU1 is the one it can read. Theoretically 
if one can tweak the firmware and the kernel driver, one could get it to 
sample the PRU0 pins instead, so you could have the PRU0 pins available.

I have designed a board prototype that converts the BeagleLogic to a 
standalone logic analyzer - 
https://theembeddedkitchen.net/announcing-beaglelogic-standalone/694 but is 
not released *yet*, although I do hope to make it available for sale in the 
near future. There's a link you can sign up to on the blog page, and I'll 
send you updates as and when it happens.

Thanks
Kumar Abhishek

On Wednesday, April 11, 2018 at 5:45:03 AM UTC+5:30, v37...@gmail.com wrote:
>
> Hello,
>
> did you make any progress or anything to share?  I use the beagle-logic on 
> the BBB, but it could be interesting on the PB too.  Any website/blog or 
> git?
>
> cheers
>
>
>
> On Saturday, April 7, 2018 at 1:32:58 AM UTC+2, Randy Rossi wrote:
>
>> I recently got the BeagleLogic logic analyzer (
>> https://github.com/abhishek-kakkar/BeagleLogic) running on the 
>> PocketBeagle under a linux 4.9 kernel.  It pretty much works as-is.  
>> However, only 4 of the 20 pins that can be configured as pruin produce any 
>> results.   My (limited) understanding is that the black and pocket 
>> processors are the same (AM335x) so I would have expected R31 in the 
>> assembly code to be able to read all pins.  Anyone have experience with 
>> getting the PRUs on the Pocket to read pins other than {p1_2, p1_4, p1_35, 
>> p2_35}?  All my pins were configured as pruin when I was testing.  Maybe 
>> some mapping that is different between the Pocket & Black? 
>>
>>
>>

-- 
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/b87e54b3-40ee-4e71-b428-5020f0e1dd84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does beaglebone-black-make-microSD-flasher-from-eMMC.sh break UDEV's Ability to See MMCBLK0P1?

[Jeff Andich]

Ok, I finally did the following:

->ran a stock console image, 2018-02-01 on my BB-X15, 
->copied the above referenced auto-mount scripts to that image on SD card.  
->Converted that SD card image containing the mount point scripts to a 
flasher image to flash the eMMC, 
->inserted a blank SD card with a single FAT partition, rebooted, and the 
automount scripts created a mountpoint on /dev/mmcblk0p1.

->then ran 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
to clone the eMMC to SD card, 
->removed that clone SD card, 
->inserted a blank SD card with a FAT partition back in the SD card slot.  
->Re-booted, and confirmed that our BB-X15 is still running from the eMMC 
image (which may have been changed by  
beaglebone-black-make-microSD-flasher-from-eMMC.sh).

After which it APPEARS like the UDEV rules in my udev script don't appear 
to be firing any more on /dev/mmcblk0p1, only /dev/mmcblk1p1

I'm not sure why beaglebone-black-make-microSD-flasher-from-eMMC.sh appears 
to modify the eMMC image which it copies from.

Does the script, for instance, switch something off with /dev/mmcblk0 to 
protect the cloning process so that the kernel temporarily doesn't report 
/dev/mmcbl0 to udev? 

I need to dig into the script (both eMMC to SD card and SD card to eMMC) to 
get a better idea of what's going on, but I was wondering whether the above 
scenario rings any bells? 

Thanks in advance!!

Jeff


More details are provided below on this mechanism for auto-mounting an SD 
card:

KERNEL!="mmcblk0p1", GOTO="mmc_job_storage_mount_end
ENV{ID_FS_LABEL}=="rootfs", GOTO="mmc_job_storage_mount_end"

(The folllowing systemd service, setup-mount-point calls a shell script to 
detect both blk devices and format and setup a mount point
 on /dev/mmcblk0p1 in the event that mmcblk1p1's label == rootfs and 
mmcblk0p1's label !=rootfs).

ACTION=="add", TAG+="systemd", 
ENV{SYSTEMD_WANTS}="setup-mount-point.service"  

LABEL="mmc_job_storage_mount_end"



On Friday, April 6, 2018 at 1:28:34 PM UTC-5, Jeff Andich wrote:
>
> *** PLEASE IGNORE THIS THREAD UNTIL i TEST THIS  SAME SCENARIO ON A 
> BB-X15  ***
>
> THIS WAS THE RESULT ON OUR CUSTOM BOARD. 
>
> Film at 11..
>
>
>
>
>
> On Friday, April 6, 2018 at 9:24:59 AM UTC-5, Jeff Andich wrote:
>>
>> Hi,
>>
>> We've got a mechanism for creating a mount point on an SD card, 
>> specifically used for storage/logging while our main application is running 
>> from eMMC (mmcblk1p1) on a BB-X15 - like platform.  The mechanism uses UDEV 
>> rules to fire on the presence of a properly formatted SD card in the slot 
>> which doesn't have label rootfs.  The UDEV rule (listed below) is looking 
>> for the presence of mmcblk0p1, and if found, initiates a systemd service 
>> which calls a shell script which then detects mmcblk0p1 (while the main 
>> image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, 
>> the script checks the formatting on the SD card, re-formats to ext4, if 
>> necessary, and then creates a mount point for storage on the card.
>>
>> Everything was working ok when I copied/created the scripts on the 
>> running eMMC image (and on a master SD card flasher image to install the 
>> image + scripts on the eMMC).
>>
>> However, when I called the script for cloning the eMMC to an SD card, 
>> beaglebone-black-make-microSD-flasher-from-eMMC.sh yesterday for the first 
>> time, the script apparently broke UDEV's ability to fire on MMCBLK0P1 on 
>> the eMMC image after the script finished uploading to SD card.   As after I 
>> powered the image running from eMMC down and inserted a "properly formatted 
>> SD card" in the slot (but without the label rootfs), our UDEV rules never 
>> fied.
>>
>> But from this state UDEV was still able to fire on the presence of 
>> MMCBLK1P1, and if I "relax" the UDEV rule to fire on either mmcblk[0-1] our 
>> shell script runs and IS able to look for  /dev/mmcblk0p1 and format the SD 
>> card if found.  But I really don't want to change this as we've shown that 
>> that the UDEV rule fires so long as I don't run the cloner script.  
>> Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, 
>> and not on MMCBLK1P1, as I don't know about the order that the drivers load 
>> when the kernel is booting..  What if the shell script runs before 
>> /dev/MMCBLK0P1 is "available"  after first detecting /dev/MMCBLK1P1??   I 
>> guess I could create a systemd service (?or cron job??) which periodically 
>> looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if 
>> found??
>>
>> More details on what's happening:
>> ***
>> The following UDEV rule triggers on our working image, running from eMMC 
>> with a properly formatted SD card in the slot, but breaks after we run, 
>> beaglebone-black-make-microSD-flasher-from-eMMC.sh .
>>  
>> KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"
>>
>> But after running 

[beagleboard] Re: Does beaglebone-black-make-microSD-flasher-from-eMMC.sh break UDEV's Ability to See MMCBLK0P1?

[Jeff Andich]

Ok, I finally did the following:

->ran a stock console image, 2018-02-01 on my BB-X15, 
->copied the above referenced auto-mount scripts to that image on SD card.  
->Converted that SD card image containing the mount point scripts to a 
flasher image to flash the eMMC, 
->inserted a blank SD card with a single FAT partition, rebooted, and the 
automount scripts created a mountpoint on /dev/mmcblk0p1.

->then ran 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
to clone the eMMC to SD card, 
->removed that clone SD card, 
->inserted a blank SD card with a FAT partition back in the SD card slot.  
->Re-booted, and confirmed that our BB-X15 is still running from the eMMC 
image (which may have been changed by  
beaglebone-black-make-microSD-flasher-from-eMMC.sh).

After which it APPEARS like the UDEV rules in my udev script don't appear 
to be firing any more on /dev/mmcblk0p1, only /dev/mmcblk1p1

I'm not sure why beaglebone-black-make-microSD-flasher-from-eMMC.sh...

Does the script switch something off with /dev/mmcblk0 to protect the 
cloning process so that the kernel temporarily doesn't report /dev/mmcbl0 
to udev? 

I need to dig into the script (both eMMC to SD card and SD card to eMMC) to 
get a better idea of what's going on, but I was wondering whether the above 
scenario rings any bells? 

Thanks!

Jeff


More details are provided below on this mechanism for auto-mounting an SD 
card:

KERNEL!="mmcblk0p1", GOTO="mmc_job_storage_mount_end
ENV{ID_FS_LABEL}=="rootfs", GOTO="mmc_job_storage_mount_end"

(The folllowing systemd service, setup-mount-point calls a shell script to 
detect both blk devices and format and setup a mount point
 on /dev/mmcblk0p1 in the event that mmcblk1p1's label == rootfs and 
mmcblk0p1's label !=rootfs).

ACTION=="add", TAG+="systemd", 
ENV{SYSTEMD_WANTS}="setup-mount-point.service"  

LABEL="mmc_job_storage_mount_end"





On Friday, April 6, 2018 at 1:28:34 PM UTC-5, Jeff Andich wrote:
>
> *** PLEASE IGNORE THIS THREAD UNTIL i TEST THIS  SAME SCENARIO ON A 
> BB-X15  ***
>
> THIS WAS THE RESULT ON OUR CUSTOM BOARD. 
>
> Film at 11..
>
>
>
>
>
> On Friday, April 6, 2018 at 9:24:59 AM UTC-5, Jeff Andich wrote:
>>
>> Hi,
>>
>> We've got a mechanism for creating a mount point on an SD card, 
>> specifically used for storage/logging while our main application is running 
>> from eMMC (mmcblk1p1) on a BB-X15 - like platform.  The mechanism uses UDEV 
>> rules to fire on the presence of a properly formatted SD card in the slot 
>> which doesn't have label rootfs.  The UDEV rule (listed below) is looking 
>> for the presence of mmcblk0p1, and if found, initiates a systemd service 
>> which calls a shell script which then detects mmcblk0p1 (while the main 
>> image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, 
>> the script checks the formatting on the SD card, re-formats to ext4, if 
>> necessary, and then creates a mount point for storage on the card.
>>
>> Everything was working ok when I copied/created the scripts on the 
>> running eMMC image (and on a master SD card flasher image to install the 
>> image + scripts on the eMMC).
>>
>> However, when I called the script for cloning the eMMC to an SD card, 
>> beaglebone-black-make-microSD-flasher-from-eMMC.sh yesterday for the first 
>> time, the script apparently broke UDEV's ability to fire on MMCBLK0P1 on 
>> the eMMC image after the script finished uploading to SD card.   As after I 
>> powered the image running from eMMC down and inserted a "properly formatted 
>> SD card" in the slot (but without the label rootfs), our UDEV rules never 
>> fied.
>>
>> But from this state UDEV was still able to fire on the presence of 
>> MMCBLK1P1, and if I "relax" the UDEV rule to fire on either mmcblk[0-1] our 
>> shell script runs and IS able to look for  /dev/mmcblk0p1 and format the SD 
>> card if found.  But I really don't want to change this as we've shown that 
>> that the UDEV rule fires so long as I don't run the cloner script.  
>> Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, 
>> and not on MMCBLK1P1, as I don't know about the order that the drivers load 
>> when the kernel is booting..  What if the shell script runs before 
>> /dev/MMCBLK0P1 is "available"  after first detecting /dev/MMCBLK1P1??   I 
>> guess I could create a systemd service (?or cron job??) which periodically 
>> looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if 
>> found??
>>
>> More details on what's happening:
>> ***
>> The following UDEV rule triggers on our working image, running from eMMC 
>> with a properly formatted SD card in the slot, but breaks after we run, 
>> beaglebone-black-make-microSD-flasher-from-eMMC.sh .
>>  
>> KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"
>>
>> But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, the 
>> only rule which will fire is:
>>
>> KERNEL!="mmcblk[0-1]p1", 

Re: [beagleboard] can't enable PRU with kernel 4.4.113-ti-r145

[Sebastián Sáez]

thanks Robert, I'll try this 1-bit mode

about the PRU now it's working. I change to kernel 4.9.88-ti-r108 and then 
apt-get upgrade

I recommend this updated guide to understand PRU
https://gist.github.com/jonlidgard/1d9e0e92b4f219f3f40edfed260b851e

regards,
Sebastián

On Wednesday, April 4, 2018 at 2:39:28 PM UTC-3, RobertCNelson wrote:
>
> On Wed, Apr 4, 2018 at 12:35 PM, Sebastián Sáez  > wrote: 
> > Thanks Robert for the script. 
> > 
> > If wifi is in 1-bit mode, does it affect its operation ?. 
>
> In theory it's be 25% as fast... 
>
> > I've already had problems with wifi and the beaglebone green wireless 
> > seeedstudio, I do not want to get worse. 
>
> Grab a newer image, it took a while to figure out all the bugs in the 
> bbgw hardware design.. 
>
> > I think it's best to modify the 433 mhz tutorial script to use another 
> PRU 
> > pin. 
>
> I would.. 
>
> > In the tutorial (step 3) this is installed, will it be necessary? 
> > git: //github.com/beagleboard/am335x_pru_package 
>
> follow the tutorial... 
>
>
> 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/12bf048b-bff8-4e89-80bb-1b2549e68cb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRUs realtime data acquisition, I2C bus and ADC

[pierrick . rauby]

Hi John, 
Thanks for the help, I looked into the iio_generic_buffer.c example and i 
patched it to disable the hardware triggers thanks to the patch presented 
on this page : https://www.teachmemicro.com/beaglebone-black-adc/ I am now 
able to reader a buffer from the different channel. 
However I have 2 majors questions that remains:

1) I only want to use on channel, then I do not want the ADC to sample the 
other one so that i'll have the maximum sampling rate. What is the best way 
to disable the channel? If I do not enable them in iio_generic_buffer.c I 
am not sure that the ADC is not going to sample this channel or not (well, 
I think it wont sample but I prefer to be sure). Is it preferable to not 
mention them on the devicetree so that Linux wont know that there are 
multiple channels on the ADC? This part is not very clear for me. 

2) To change the sample frequency of the ADC you mentioned that it is done 
using the device tree however I did not find any argument on the ADC 
devicetree to change the sampling frequency. I read the discussion you had 
on this post (https://patchwork.kernel.org/patch/9391487/ ) but it is not 
clear if the frequency setting is done using the kernel module or 
devicetrees. Could you explain me this please? 

Thanks a lot 

Pierrick 

Le mercredi 28 mars 2018 00:45:01 UTC-4, john3909 a écrit :
>
> Look at the kernel source under tools/iio for examples on how to use IIO.
>
> Regards,
> John
>
>
>
>
>
> On Mar 27, 2018, at 12:10 PM, pierric...@gadz.org  wrote:
>
> Hi John, 
>
> Sorry for the late answer, I had hard time using the PRUs and I am now 
> going to use the IIO ADC driver, I am able to read the sample with the cat 
> command in /sys/bus/iio/devices/iio:device0/in_voltage3_raw 
> However I am not able to use Libiio in order to read data from a user 
> space application, I am reading (nil) instead of my data. Do you have any 
> idea of where does the problem comes from ? 
>
> Here is the code I am using in the user space :
>
>
> #define _BSD_SOURCE
> #define _GNU_SOURCE
> #define _DEFAULT_SOURCE
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #ifdef __APPLE__
> #include 
> #else
> #include 
> #endif
>
> struct iio_context *ctx;
> struct iio_device *dev;
> struct iio_channel *ch;
>
> int main()
> {
>   ctx = iio_create_default_context();
>   dev = iio_context_get_device(ctx, 0);
>   ch = iio_device_get_channel(dev, 3);
>
>
>   iio_device_attr_write_longlong(dev, "sample_rate", 100);
>   iio_channel_attr_write_double(ch, "scale", 1);
>
>   iio_channel_enable(ch);
>
>   char *a = iio_device_get_data(dev);
>   printf("%p\n", a);
>
>   iio_channel_disable(ch);
>
>   return 0;
> }
>
> Thanks 
>
> Pierrick 
>
>
> Le lundi 26 février 2018 16:46:11 UTC-5, john3909 a écrit :
>>
>> The IIO ADC driver can run at 800K samples per second. Here is the patch 
>> that made that possible. 
>>
>> https://patchwork.kernel.org/patch/9391487/
>>
>> I can confirm that I have tested the driver at 800Ksps and it works fine 
>> as long as you have a proper low impedance source for each ADC channel. CPU 
>> utilization was about 5% if I recall and that was probably used by the iiod 
>> daemon, which I used to display the waveform on a remote Linux app. 
>>
>> There is example code in the original Starterware for McSPI, which should 
>> work fine if you are using the PRU low level drivers. 
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 26, 2018, at 12:56 PM, pierric...@gadz.org wrote:
>>
>> Thanks John, 
>>
>> I am now working with the starterware_PRU but i did not find examples for 
>> using the McSPI with the PRU, do you think it will be hard to adapt the 
>> initial code to the PRU ? 
>> By the way, looking to the IIO driver documentation, it seems that for 
>> the AM335x chip the max sampling rate is only 200k samples per second which 
>> may not be enough :
>> http://processors.wiki.ti.com/index.php/Linux_Core_ADC_Users_Guide ; am 
>> I right ? 
>>
>>
>> Thanks 
>>
>> Pierrick 
>>
>> Le lundi 19 février 2018 23:15:50 UTC-5, john3909 a écrit :
>>>
>>> Like I said, it was based on Starterware, so search Github for 
>>> starterware and you will see a project starterware_PRU. It does use the 
>>> mcspi, so it is not a bitbang implementation. 
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Feb 19, 2018, at 7:33 PM, pierric...@gadz.org wrote:
>>>
>>> Thanks John for you answer, I was quit busy last week so I worked on 
>>> this during the Weekend. 
>>>
>>> Unfortunately, I was not able to find a project that is using the SPI 
>>> and I2C interface with the PRU, I only found this one : 
>>>
>>> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/SPI-Master-Controller
>>>  
>>> But it is using bit banging for the SPI part and not using the on-board 
>>> pull-up resistors for the I2C part.
>>>
>>> Concerning the ADC, I'll have a loook at the UIIO drivers in the coming 
>>> days it seems that it meets my need in term of real-time