[beagleboard] Re: Has Anyone Had Difficulty Outputting GPIO, UART, or I2C on the BB-X15's Expansion Header?

2017-12-05 Thread Jeff Andich 


On Tuesday, December 5, 2017 at 6:25:17 PM UTC-6, Jeff Andich wrote:
>
> Note: Per the 572xEVM_REVA3 schematic and the pad configuration of our 
> boot loader, gpio5_8 comes out on pin 55 of the P17 expansion header on the 
> BB-X15.
>
> Incidentally, I tried varying the brightness in 
> /sys/class/leds/gpio_jeff_test to see if the level of gpio5_8 would change 
> on the scope, but no luck  Varying the brightness works great with the 
> blinking leds (gpio7_8, 7_9, 7_14, 7_15) on the top of the bb-x15.  You can 
> turn them on an off by echoing different values in for "brightness."
>
> I was wondering if the expansion headers could be mis-labled on my board.  
> So I tried moving the breakout board around to all 4 of the expansion 
> headers, but keeping the scope probe on the same pin, pin55. But no luck.
>
> I also tried the ADAFRUIT GPIO module in Python, yesterday, but it looks 
> like there isn't yet a Python module which exposes all of the gpio chips 
> for the BB-X15.  Please correct me if I'm wrong.
>
> Also, I have the following gpio fragment in my dts.
>
>  {
> ti,no-reset-on-init;
> ti,no-idle-on-init;
> };
>
> Maybe a reasonable next-step is to find some known signals coming out on 
> the expansion headers, and then reverse engineer how they're getting 
> generated..  Maybe video signals or touchscreen input signals for the 
> external touchscreen would be a good place to start
>
> Thanks!
>

 

>
> On Monday, December 4, 2017 at 5:49:59 PM UTC-6, Jeff Andich wrote:
>>
>> Hi,
>>
>> Has anyone had any difficulty outputting GPIO,UART, I2C, signals from the 
>> BB-X15's expansion header?  I haven't yet been able to successfully get 
>> GPIO and/or UART data to come out on the associated pins of the 4 expansion 
>> ports of the am572xEVM/BB-X15.  We made a PCBA breakout board which breaks 
>> out 30/60 signals on each header. 
>>
>> If you were able to get this working, what were some of the key 
>> considerations?
>>
>> I stumbled across this post on TI E2E, where others were encountering 
>> issues with this as well.
>>
>>
>> https://e2e.ti.com/support/embedded/linux/f/354/p/595855/2206686#pi317016=1
>>  
>>
>> Here I THINK the TI employee indicated that one of the critical steps is 
>> specifying the correct offset in the device tree for the pad configuration 
>> register of interest.  But when I look at the device tree, 
>> am57xx-evm-reva3, and the associated included dtsi and dts files, I didn't 
>> see this kind of thing for GPIO pins:
>>
>> gpio5_pins: pinmux_gpio5_pins {
>> pinctrl-single,pins = <
>> DRA7XX_CORE_IOPAD(0x, (PIN_INPUT | MUX_MODEX))
>> DRA7XX_CORE_IOPAD(0x, (PIN_OUTPUT| MUX_MODE3))
>> >;
>> };
>>
>>
>> in the case of attempting to set GPIO5_8, and using sysfs commands, echo 
>> 1,0 > /sys/class/gpio/gpio136/value (after setting the direction to OUT), 
>> the value and direction files always jive with what gets echo'd into the 
>> file - however the state of the line doesn't change.
>>
>> I DO have a modified board.c file, but I'm pretty confident the pinmux in 
>> mux_data.h for GPIO5_8 is the same as the development board.  Granted this 
>> maybe an older revision, as I grabbed one of the earlier revisions of 
>> u-boot 2017.01.
>>  
>> I even tried hacking,  am57xx-beagle-x15-common.dtsi by adding another 
>> phantom LED fragment/cluster.
>>
>> .
>> .
>> .
>> leds {
>> .
>> .
>> .
>>   led@4 {
>> label = "gpio_jeff_test";
>> gpios = < 8 GPIO_ACTIVE_HIGH>;
>> linux,default-trigger = "ide-disk";
>> default-state = "off";
>> };
>> };
>>
>> The good news is, the  gpio line is 3.3V with this statement.
>> The bad news: When I change this to GPIO_ACTIVE_LOW, gpio5_8 is still 
>> stuck at 3.3V..
>>
>>
>> The only luck I've had to date is on our custom hardware board, coupling 
>> GPIO5_8 with UART5 for the rts line, and then toggle the GPIO line via 
>> sysfs commands and by toggling the state of the rtscts flag in Pyserial in 
>> Python (This after swapping out the 8250 serial driver for the OMAP driver):
>>
>>  {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> status = "okay";
>>   rts-gpio = < 8 GPIO_ACTIVE_HIGH>;
>> rs485-rts-active-high;
>> rs485-rts-delay = <0 0>;
>> linux,rs485-enabled-at-boot-time;
>> };
>>
>>
>> Can you maybe provide any clues to steer us in the right direction?
>>
>>
>> Thanks!!!
>>
>> Jeff
>>
>>

-- 
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

[beagleboard] Re: Has Anyone Had Difficulty Outputting GPIO, UART, or I2C on the BB-X15's Expansion Header?

2017-12-05 Thread Jeff Andich 
Note: Per the 572xEVM_REVA3 schematic and the pad configuration of our boot 
loader, gpio5_8 comes out on pin 55 of the P17 expansion header on the 
BB-X15.

Incidentally, I tried varying the brightness in 
/sys/class/leds/gpio_jeff_test to see if the level of gpio5_8 would change 
on the scope, but no luck  Varying the brightness works great with the 
blinking leds (gpio7_8, 7_9, 7_14, 7_15) on the top of the bb-x15.  You can 
turn them on an off by echoing different values in for "brightness."

I was wondering if the expansion headers could be mis-labled on my board.  
So I tried moving the breakout board around to all 4 of the expansion 
headers, but keeping the scope probe on the same pin, pin55. But no luck.

I also tried the ADAFRUIT GPIO module in Python, yesterday, but it looks 
like there isn't yet a Python module which exposes all of the gpio chips 
for the BB-X15.  Please correct me if I'm wrong.

Also, I have the following gpio fragment in my dts.

 {
ti,no-reset-on-init;
ti,no-idle-on-init;
};

Maybe a reasonable next-step is to find some known signals coming out on 
the expansion headers, and then reverse engineer how they're getting 
generated..  This is certainly the case with the LXQT

Tomorrow, I'll try explicit declarations for 



On Monday, December 4, 2017 at 5:49:59 PM UTC-6, Jeff Andich wrote:
>
> Hi,
>
> Has anyone had any difficulty outputting GPIO,UART, I2C, signals from the 
> BB-X15's expansion header?  I haven't yet been able to successfully get 
> GPIO and/or UART data to come out on the associated pins of the 4 expansion 
> ports of the am572xEVM/BB-X15.  We made a PCBA breakout board which breaks 
> out 30/60 signals on each header. 
>
> If you were able to get this working, what were some of the key 
> considerations?
>
> I stumbled across this post on TI E2E, where others were encountering 
> issues with this as well.
>
> https://e2e.ti.com/support/embedded/linux/f/354/p/595855/2206686#pi317016=1
>  
>
> Here I THINK the TI employee indicated that one of the critical steps is 
> specifying the correct offset in the device tree for the pad configuration 
> register of interest.  But when I look at the device tree, 
> am57xx-evm-reva3, and the associated included dtsi and dts files, I didn't 
> see this kind of thing for GPIO pins:
>
> gpio5_pins: pinmux_gpio5_pins {
> pinctrl-single,pins = <
> DRA7XX_CORE_IOPAD(0x, (PIN_INPUT | MUX_MODEX))
> DRA7XX_CORE_IOPAD(0x, (PIN_OUTPUT| MUX_MODE3))
> >;
> };
>
>
> in the case of attempting to set GPIO5_8, and using sysfs commands, echo 
> 1,0 > /sys/class/gpio/gpio136/value (after setting the direction to OUT), 
> the value and direction files always jive with what gets echo'd into the 
> file - however the state of the line doesn't change.
>
> I DO have a modified board.c file, but I'm pretty confident the pinmux in 
> mux_data.h for GPIO5_8 is the same as the development board.  Granted this 
> maybe an older revision, as I grabbed one of the earlier revisions of 
> u-boot 2017.01.
>  
> I even tried hacking,  am57xx-beagle-x15-common.dtsi by adding another 
> phantom LED fragment/cluster.
>
> .
> .
> .
> leds {
> .
> .
> .
>   led@4 {
> label = "gpio_jeff_test";
> gpios = < 8 GPIO_ACTIVE_HIGH>;
> linux,default-trigger = "ide-disk";
> default-state = "off";
> };
> };
>
> The good news is, the  gpio line is 3.3V with this statement.
> The bad news: When I change this to GPIO_ACTIVE_LOW, gpio5_8 is still 
> stuck at 3.3V..
>
>
> The only luck I've had to date is on our custom hardware board, coupling 
> GPIO5_8 with UART5 for the rts line, and then toggle the GPIO line via 
> sysfs commands and by toggling the state of the rtscts flag in Pyserial in 
> Python (This after swapping out the 8250 serial driver for the OMAP driver):
>
>  {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> status = "okay";
>   rts-gpio = < 8 GPIO_ACTIVE_HIGH>;
> rs485-rts-active-high;
> rs485-rts-delay = <0 0>;
> linux,rs485-enabled-at-boot-time;
> };
>
>
> Can you maybe provide any clues to steer us in the right direction?
>
>
> Thanks!!!
>
> Jeff
>
>

-- 
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/de1e5499-9995-40c6-aed3-71d35795ca1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is cape manager obsolete? What about device tree overlays?

2017-12-05 Thread Mark A. Yoder 
Well, I though I had a solution.  I switched from the 4.9 kernel to 4.4
bone$ *uname -a*
Linux bone-5eca 4.4.91-ti-r137 #1 SMP Tue Nov 7 01:13:03 UTC 2017 armv7l 
GNU/Linux
and I still can't unexport the pins I want for the LCD.
bone$ *sudo bash*
bone# *echo 116 > unexport* 
bash: echo: write error: Invalid argument

I'm not sure what to try next.

--Mark

On Wednesday, November 29, 2017 at 9:24:39 PM UTC-5, Yoder, Mark A wrote:
>
> I can't unexport them.
>
>
> root@bone-5eca:/sys/class/gpio# echo 116 > unexport 
> bash: echo: write error: Invalid argument
>
>
> --Mark A. Yoder, PhD
>   Electrical and Computer Engineering
>   Rose-Hulman Institute of Technology
>   812-233-3219
> --
> *From:* Robert Nelson 
> *Sent:* Wednesday, November 29, 2017 9:22:10 PM
> *To:* Beagle Board; Mark Yoder
> *Subject:* Re: [beagleboard] Is cape manager obsolete? What about device 
> tree overlays? 
>  
> On Wed, Nov 29, 2017 at 8:08 PM, Mark A. Yoder  > wrote:
> > I see that if I edit /boot/uEnv.txt and comment out:
> > #enable_uboot_cape_universal=1
> > I can then access all sorts of gpio pins. But now I can't run config-pin 
> on
> > them since there is no pinmux entry in /sys/devices/platform/ocp.
> >
> > Is there a way to free up a few gpio pins to drive the LCD and keep the 
> rest
> > pinmux-able?
>
> I'm not sure why it's broken now, but you should be able to un-export
> all those pins to drive the LCD, Jason's done it before..
>
> 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/935cec68-17ca-4c56-b11c-564b322384f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black Industrial universal cape not working...

2017-12-05 Thread Robert Nelson 
On Tue, Dec 5, 2017 at 4:30 PM, Daniel Kulp  wrote:
>
>
>
> Using the 9.1 based image, I get:
>
> eeprom:[A335BNLTEIA03716BBBK1337]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2017-08-31]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> 2017.09-2-g0f3f1c7907]
> kernel:[4.4.91-ti-r137]
> nodejs:[v6.12.0]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
> uboot_overlay_options:[disable_uboot_overlay_adc=1]
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg:[bb-cape-overlays]:[4.4.20171107.0-0rcnee1~stretch+20171107]
> pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
>
> Using the latest stuff, I get:
> git:/opt/scripts/:[e5c23dc2a45f5c9ace291dd32e7c3d79edc1932d]
> eeprom:[A335BNLTEIA03716BBBK1337]
> model:[Octavo_Systems_OSD3358-SM-RED]
> dogtag:[BeagleBoard.org Debian Image 2017-10-10]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> 2017.11-2-g7b415acfc1]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> 2017.11-2-g7b415acfc1]
> kernel:[4.4.91-ti-r137]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
> uboot_overlay_options:[disable_uboot_overlay_adc=1]
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg:[bb-cape-overlays]:[4.4.20171126.0-0rcnee1~stretch+20171126]
> pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
>

Ah crap, fubar on me, that board's eeprom was never implemented in our
u-boot, it just worked till i added the latest board and then broke
it..

I have that board somewhere here at work, i'll get it fixed tomorrow..

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

Re: [beagleboard] Re: Beaglebone Black Industrial universal cape not working...

2017-12-05 Thread Daniel Kulp 



Using the 9.1 based image, I get:

eeprom:[A335BNLTEIA03716BBBK1337]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2017-08-31]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.09-2-g0f3f1c7907]
kernel:[4.4.91-ti-r137]
nodejs:[v6.12.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171107.0-0rcnee1~stretch+20171107]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]

Using the latest stuff, I get:
git:/opt/scripts/:[e5c23dc2a45f5c9ace291dd32e7c3d79edc1932d]
eeprom:[A335BNLTEIA03716BBBK1337]
model:[Octavo_Systems_OSD3358-SM-RED]
dogtag:[BeagleBoard.org Debian Image 2017-10-10]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.11-2-g7b415acfc1]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2017.11-2-g7b415acfc1]
kernel:[4.4.91-ti-r137]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171126.0-0rcnee1~stretch+20171126]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]







On Tuesday, December 5, 2017 at 5:19:18 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Dec 5, 2017 at 4:13 PM, Daniel Kulp  
> wrote: 
> > 
> > Uhgg... also just discovered that the /proc/device-tree-model now reads: 
> > 
> > Octavo Systems OSD3358-SM-RED 
> > 
> > On the older stretch 9.1 based image I have, it reads "TI AM335x 
> BeagleBone 
> > Black" just like the black's.That's going to break a bunch of things 
> for 
> > me as well.  :(I need to use the industrial version as we hit 
> > temperatures well below freezing.   Is this a uBoot thing?   Would 
> dropping 
> > back to the older uBoot help? 
>
>
> Your board has a weird eeprom, please run: 
>
> sudo /opt/scripts/tools/version.sh 
>
> That board should have: 
>
> https://github.com/beagleboard/image-builder/blob/master/readme.md 
>
> Element14 BeagleBone Black Industrial: 
>
>   A0: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 45 49 41 30 
> |.U3.A335BNLTEIA0|] 
>
> 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/20ad5de5-8a5c-4554-b75c-7e9c575370f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black Industrial universal cape not working...

2017-12-05 Thread Robert Nelson 
On Tue, Dec 5, 2017 at 4:13 PM, Daniel Kulp  wrote:
>
> Uhgg... also just discovered that the /proc/device-tree-model now reads:
>
> Octavo Systems OSD3358-SM-RED
>
> On the older stretch 9.1 based image I have, it reads "TI AM335x BeagleBone
> Black" just like the black's.That's going to break a bunch of things for
> me as well.  :(I need to use the industrial version as we hit
> temperatures well below freezing.   Is this a uBoot thing?   Would dropping
> back to the older uBoot help?


Your board has a weird eeprom, please run:

sudo /opt/scripts/tools/version.sh

That board should have:

https://github.com/beagleboard/image-builder/blob/master/readme.md

Element14 BeagleBone Black Industrial:

  A0: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 45 49 41 30 |.U3.A335BNLTEIA0|]

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

[beagleboard] Re: Beaglebone Black Industrial universal cape not working...

2017-12-05 Thread Daniel Kulp 

Uhgg... also just discovered that the /proc/device-tree-model now reads:

Octavo Systems OSD3358-SM-RED

On the older stretch 9.1 based image I have, it reads "TI AM335x BeagleBone 
Black" just like the black's.That's going to break a bunch of things 
for me as well.  :(I need to use the industrial version as we hit 
temperatures well below freezing.   Is this a uBoot thing?   Would dropping 
back to the older uBoot help?




On Tuesday, December 5, 2017 at 4:46:22 PM UTC-5, Daniel Kulp wrote:
>
>
> I have an image that works fine on a Beaglebone Black and Beaglebone 
> green, but it's not working properly on the "red" industrial version.   For 
> some reason, the uboot_capemgr isn't being loaded by uboot on the Red 
> whereas it is using the exact same SD card/Image as I use on the others.   
>
> Connecting a serial cable, on the normal black, I see:
>
> loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
> 57290 bytes read in 263 ms (211.9 KiB/s)
> uboot_overlays: [fdt_buffer=0x6] ...
> uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...
> 378 bytes read in 363 ms (1000 Bytes/s)
> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
> 1105 bytes read in 108 ms (9.8 KiB/s)
> uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
> uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
> by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
> 853 bytes read in 466 ms (1000 Bytes/s)
> uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ...
> 92641 bytes read in 515 ms (174.8 KiB/s)
> loading /boot/initrd.img-4.4.91-ti-r137 ...
> 6259413 bytes read in 438 ms (13.6 MiB/s)
> debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet] ...
>
>
> But on the Red, I see:
>
> loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
> 57290 bytes read in 262 ms (212.9 KiB/s)
> uboot_overlays: [fdt_buffer=0x6] ...
> uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ...
> 441 bytes read in 532 ms (0 Bytes/s)
> uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ...
> 285 bytes read in 450 ms (0 Bytes/s)
> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
> 1105 bytes read in 107 ms (9.8 KiB/s)
> uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
> uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
> by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
> 853 bytes read in 459 ms (1000 Bytes/s)
> loading /boot/initrd.img-4.4.91-ti-r137 ...
> 6259413 bytes read in 438 ms (13.6 MiB/s)
> debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool=1M net.ifnames=0 quiet] 
>
> Is there something about the OSD3358-00A0 and M-BB-OSD3358-SM-RED-00A0 
> compared to the normal AM335X-20-00A0 that would cause the universal cape 
> manager to not be detected or loaded? Is there an easy workaround?   
>

-- 
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/3bdb4f7f-58f7-494d-8139-83d934d2f030%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Black Industrial universal cape not working...

2017-12-05 Thread Daniel Kulp 
It's the Element14 Beaglebone Black Industrial

BBONE-BLACK-IND-4G

http://www.newark.com/element14/bbone-black-ind-4g/beaglebone-black-rev-c-cortex/dp/53Y3717?CMP=KNC-GUSA-GEN-KWL=|pcrid|190494657105|=EAIaIQobChMIlpfu1fDz1wIVk0sNCh1XjAUUEAAYAyAAEgIGLvD_BwE

Thanks!
Dan


On Tuesday, December 5, 2017 at 4:56:37 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Dec 5, 2017 at 3:46 PM, Daniel Kulp  
> wrote: 
> > 
> > I have an image that works fine on a Beaglebone Black and Beaglebone 
> green, 
> > but it's not working properly on the "red" industrial version.   For 
> some 
> > reason, the uboot_capemgr isn't being loaded by uboot on the Red whereas 
> it 
> > is using the exact same SD card/Image as I use on the others. 
> > 
> > Connecting a serial cable, on the normal black, I see: 
> > 
> > loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ... 
> > 57290 bytes read in 263 ms (211.9 KiB/s) 
> > uboot_overlays: [fdt_buffer=0x6] ... 
> > uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ... 
> > 378 bytes read in 363 ms (1000 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ... 
> > 1105 bytes read in 108 ms (9.8 KiB/s) 
> > uboot_overlays: uboot loading of 
> [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> > disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]... 
> > uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] 
> disabled 
> > by /boot/uEnv.txt [disable_uboot_overlay_adc=1]... 
> > uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ... 
> > 853 bytes read in 466 ms (1000 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ... 
> > 92641 bytes read in 515 ms (174.8 KiB/s) 
> > loading /boot/initrd.img-4.4.91-ti-r137 ... 
> > 6259413 bytes read in 438 ms (13.6 MiB/s) 
> > debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> > root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> > net.ifnames=0 quiet] ... 
> > 
> > 
> > But on the Red, I see: 
> > 
> > loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ... 
> > 57290 bytes read in 262 ms (212.9 KiB/s) 
> > uboot_overlays: [fdt_buffer=0x6] ... 
> > uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ... 
> > 441 bytes read in 532 ms (0 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ... 
> > 285 bytes read in 450 ms (0 Bytes/s) 
> > uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ... 
> > 1105 bytes read in 107 ms (9.8 KiB/s) 
> > uboot_overlays: uboot loading of 
> [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> > disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]... 
> > uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] 
> disabled 
> > by /boot/uEnv.txt [disable_uboot_overlay_adc=1]... 
> > uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ... 
> > 853 bytes read in 459 ms (1000 Bytes/s) 
> > loading /boot/initrd.img-4.4.91-ti-r137 ... 
> > 6259413 bytes read in 438 ms (13.6 MiB/s) 
> > debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> > rootwait coherent_pool=1M net.ifnames=0 quiet]  
> > 
> > Is there something about the OSD3358-00A0 and M-BB-OSD3358-SM-RED-00A0 
> > compared to the normal AM335X-20-00A0 that would cause the universal 
> cape 
> > manager to not be detected or loaded? Is there an easy workaround? 
>
> Which red board? 
>
> 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/07c68fac-ff4e-4e2c-9c75-7bec4802c03c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Black Industrial universal cape not working...

2017-12-05 Thread Robert Nelson 
On Tue, Dec 5, 2017 at 3:46 PM, Daniel Kulp  wrote:
>
> I have an image that works fine on a Beaglebone Black and Beaglebone green,
> but it's not working properly on the "red" industrial version.   For some
> reason, the uboot_capemgr isn't being loaded by uboot on the Red whereas it
> is using the exact same SD card/Image as I use on the others.
>
> Connecting a serial cable, on the normal black, I see:
>
> loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
> 57290 bytes read in 263 ms (211.9 KiB/s)
> uboot_overlays: [fdt_buffer=0x6] ...
> uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...
> 378 bytes read in 363 ms (1000 Bytes/s)
> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
> 1105 bytes read in 108 ms (9.8 KiB/s)
> uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo]
> disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
> uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled
> by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
> 853 bytes read in 466 ms (1000 Bytes/s)
> uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ...
> 92641 bytes read in 515 ms (174.8 KiB/s)
> loading /boot/initrd.img-4.4.91-ti-r137 ...
> 6259413 bytes read in 438 ms (13.6 MiB/s)
> debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
> net.ifnames=0 quiet] ...
>
>
> But on the Red, I see:
>
> loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
> 57290 bytes read in 262 ms (212.9 KiB/s)
> uboot_overlays: [fdt_buffer=0x6] ...
> uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ...
> 441 bytes read in 532 ms (0 Bytes/s)
> uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ...
> 285 bytes read in 450 ms (0 Bytes/s)
> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
> 1105 bytes read in 107 ms (9.8 KiB/s)
> uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo]
> disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
> uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled
> by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
> 853 bytes read in 459 ms (1000 Bytes/s)
> loading /boot/initrd.img-4.4.91-ti-r137 ...
> 6259413 bytes read in 438 ms (13.6 MiB/s)
> debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4
> rootwait coherent_pool=1M net.ifnames=0 quiet] 
>
> Is there something about the OSD3358-00A0 and M-BB-OSD3358-SM-RED-00A0
> compared to the normal AM335X-20-00A0 that would cause the universal cape
> manager to not be detected or loaded? Is there an easy workaround?

Which red board?

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

[beagleboard] BeagleBoard X15 Weight

2017-12-05 Thread rjdyk 
Does anyone know the weight of the X15 board?
It's not available on any of the forums I've checked and when I contacted a 
supplier they didn't have any information on the weight.

Thanks

-- 
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/b317f4f3-52c6-40f8-a983-6d5b212a88ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone Black Industrial universal cape not working...

2017-12-05 Thread Daniel Kulp 

I have an image that works fine on a Beaglebone Black and Beaglebone green, 
but it's not working properly on the "red" industrial version.   For some 
reason, the uboot_capemgr isn't being loaded by uboot on the Red whereas it 
is using the exact same SD card/Image as I use on the others.   

Connecting a serial cable, on the normal black, I see:

loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
57290 bytes read in 263 ms (211.9 KiB/s)
uboot_overlays: [fdt_buffer=0x6] ...
uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...
378 bytes read in 363 ms (1000 Bytes/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1105 bytes read in 108 ms (9.8 KiB/s)
uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
853 bytes read in 466 ms (1000 Bytes/s)
uboot_overlays: loading /lib/firmware/univ-bbb-Exx-00A0.dtbo ...
92641 bytes read in 515 ms (174.8 KiB/s)
loading /boot/initrd.img-4.4.91-ti-r137 ...
6259413 bytes read in 438 ms (13.6 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet] ...


But on the Red, I see:

loading /boot/dtbs/4.4.91-ti-r137/am335x-boneblack-uboot.dtb ...
57290 bytes read in 262 ms (212.9 KiB/s)
uboot_overlays: [fdt_buffer=0x6] ...
uboot_overlays: loading /lib/firmware/OSD3358-00A0.dtbo ...
441 bytes read in 532 ms (0 Bytes/s)
uboot_overlays: loading /lib/firmware/M-BB-OSD3358-SM-RED-00A0.dtbo ...
285 bytes read in 450 ms (0 Bytes/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1105 bytes read in 107 ms (9.8 KiB/s)
uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...
uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled 
by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...
uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
853 bytes read in 459 ms (1000 Bytes/s)
loading /boot/initrd.img-4.4.91-ti-r137 ...
6259413 bytes read in 438 ms (13.6 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 quiet] 

Is there something about the OSD3358-00A0 and M-BB-OSD3358-SM-RED-00A0 
compared to the normal AM335X-20-00A0 that would cause the universal cape 
manager to not be detected or loaded? Is there an easy workaround?   

-- 
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/9f065fdf-80c0-4ed0-affa-5bc3ae4cd980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] BeagelBoard X15 Weight

2017-12-05 Thread Gerald Coley 
I don't know off the top of my head. I would need to go a weigh one.

Gerald


From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of rj...@umich.edu
Sent: Tuesday, December 5, 2017 1:17 PM
To: BeagleBoard 
Subject: [beagleboard] BeagelBoard X15 Weight


Does anyone know the weight of the X15?
I haven't been able to find it on any forums and when I contacted a supplier 
they didn't have data on its weight.
--
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/408cbddd-2fda-42fb-8269-565f0320e434%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/8f279041511d4826b07e854e716cc526%40winhexbeus11.winus.mail.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] X15 Weight

2017-12-05 Thread rjdyk 
Does anyone know the weight of the X15 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/bdc2a989-c8ac-456e-b570-da9bbf6a02ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagelBoard X15 Weight

2017-12-05 Thread rjdyk 

Does anyone know the weight of the X15?
I haven't been able to find it on any forums and when I contacted a 
supplier they didn't have data on its weight.

-- 
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/408cbddd-2fda-42fb-8269-565f0320e434%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to use PocketBeagle analog inputs 5-7?

2017-12-05 Thread Ken Shirriff 
Thanks, Jason. Your magic i2cset commands worked and now I can use analog
input 7.

Ken

On Tue, Dec 5, 2017 at 11:39 AM, Jason Kridner  wrote:

>
>
> On Tue, Dec 5, 2017 at 2:21 PM Ken Shirriff 
> wrote:
>
>> Thanks Robert and Jason. For pin 5 and 6, your solution works:
>>
>> Pin 5:
>> $ config-pin P2_35 gpio
>> $ echo in > /sys/class/gpio/gpio86/direction
>> $ cat /sys/bus/iio/devices/iio:device0/in_voltage5_raw
>> 1571
>>
>> Pin 6:
>> $ config-pin P1_2 gpio
>> $ echo in > /sys/class/gpio/gpio87/direction
>> $ cat /sys/bus/iio/devices/iio:device0/in_voltage6_raw
>> 1571
>>
>> Because of the voltage divider, the values are half of the "normal"
>> values.
>>
>> But I still can't get pin 7 to work:
>> $ while [ 1 ]; do cat /sys/bus/iio/devices/iio:device0/in_voltage7_raw;
>> done
>> This gives me a sequence of values starting around 1600 dropping by about
>> 10 every second, unrelated to my input, slowing down to about 658. Sort of
>> like the voltage if you were discharging a capacitor.
>>
>> So analog input 7 seems to be measuring something, but I don't know what.
>> Maybe some PMIC thing?
>>
>
> I'm not sure how to check the status of the analog mux.  Someone posted a
> driver patch on the TI e2e forum to change the status. Maybe we should
> carry that patch or help submit to mainline?
>
> https://e2e.ti.com/support/arm/sitara_arm/f/791/t/256567
>
> Out of curiosity, can you try:
>
> sudo i2cset -y -f 0 0x24 9 5
> sudo i2cget -y -f 0 0x24 9
> sudo cat /sys/bus/iio/devices/iio:device0/in_voltage7_raw
>
> I pulled the magic numbers from the patch and the files it references.
>
>
>>
>> (I'm using Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC
>> 2017 armv7l GNU/Linux)
>>
>> Ken
>>
>>
>> On Tuesday, December 5, 2017 at 10:03:06 AM UTC-8, Jason Kridner wrote:
>>>
>>>
>>>
>>> On Tue, Dec 5, 2017 at 10:00 AM Robert Nelson 
>>> wrote:
>>>
>> On Sun, Dec 3, 2017 at 1:07 PM, Ken Shirriff  wrote:
 > I can read analog inputs 0-4 from
 > /sys/bus/iio/devices/iio:device0/in_voltageN_raw but I can't get
 analog
 > inputs 5-7 to work. Inputs 5 and 6 don't have analog as a choice in
 > config-pin:
 >
 > $ config-pin -l P1_2
 > default gpio gpio_pu gpio_pd pruout pruin
 >
 > Analog input 7 (P2_36) doesn't have any other function, but it
 ignores any
 > analog input voltage.
 >
 > Is there a trick to using inputs 5-7 or is support under development?

 Since 5-7 ADC's are shared with a normal pin, you need to stick the
 gpio in gpio mode with config-pin.. (no pull-up, no pull-down) then it
 might work..

 Haven't personally tried this yet..

>>>
>>> I tested all 3 inputs as part of the board bring-up/validation process,
>>> but I was using a different device tree. I'm trying to get back to it with
>>> what Robert ships in the latest images, hopefully in the next day or so,
>>> but I'd like to provide some notes that might be of some use:
>>>
>>> For 5 and 6, yeah, Robert's right on making sure the GPIO is set to
>>> input mode (should be default?) and that there is no pull-up/pull-down
>>> enabled on the pin. Do note, however, that there is a 10k pull-down due to
>>> the resistor divider on the input. All voltages on the ADC will be half of
>>> what they are on the headerpin.
>>>
>>> For 7, there is an analog mux, but it should default to the status of
>>> the pin. There are some voltages internal to the PMIC that could be read,
>>> put the header pin status should be the default.
>>>
>>>
>>
 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...@googlegroups.com.
>>>
>>>
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/beagleboard/CAOCHtYjKoCF5-ZULWhZUdefCMZo84H1g_
 1tmPQjaUFOO4v8Xpg%40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> https://beagleboard.org/about
>>>
>> --
>> 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/8a366e68-aa6f-4847-9a14-d2abb782d351%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>

Re: [beagleboard] How to use PocketBeagle analog inputs 5-7?

2017-12-05 Thread Jason Kridner 
On Tue, Dec 5, 2017 at 2:21 PM Ken Shirriff  wrote:

> Thanks Robert and Jason. For pin 5 and 6, your solution works:
>
> Pin 5:
> $ config-pin P2_35 gpio
> $ echo in > /sys/class/gpio/gpio86/direction
> $ cat /sys/bus/iio/devices/iio:device0/in_voltage5_raw
> 1571
>
> Pin 6:
> $ config-pin P1_2 gpio
> $ echo in > /sys/class/gpio/gpio87/direction
> $ cat /sys/bus/iio/devices/iio:device0/in_voltage6_raw
> 1571
>
> Because of the voltage divider, the values are half of the "normal" values.
>
> But I still can't get pin 7 to work:
> $ while [ 1 ]; do cat /sys/bus/iio/devices/iio:device0/in_voltage7_raw;
> done
> This gives me a sequence of values starting around 1600 dropping by about
> 10 every second, unrelated to my input, slowing down to about 658. Sort of
> like the voltage if you were discharging a capacitor.
>
> So analog input 7 seems to be measuring something, but I don't know what.
> Maybe some PMIC thing?
>

I'm not sure how to check the status of the analog mux.  Someone posted a
driver patch on the TI e2e forum to change the status. Maybe we should
carry that patch or help submit to mainline?

https://e2e.ti.com/support/arm/sitara_arm/f/791/t/256567

Out of curiosity, can you try:

sudo i2cset -y -f 0 0x24 9 5
sudo i2cget -y -f 0 0x24 9
sudo cat /sys/bus/iio/devices/iio:device0/in_voltage7_raw

I pulled the magic numbers from the patch and the files it references.


>
> (I'm using Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC
> 2017 armv7l GNU/Linux)
>
> Ken
>
>
> On Tuesday, December 5, 2017 at 10:03:06 AM UTC-8, Jason Kridner wrote:
>>
>>
>>
>> On Tue, Dec 5, 2017 at 10:00 AM Robert Nelson 
>> wrote:
>>
> On Sun, Dec 3, 2017 at 1:07 PM, Ken Shirriff  wrote:
>>> > I can read analog inputs 0-4 from
>>> > /sys/bus/iio/devices/iio:device0/in_voltageN_raw but I can't get analog
>>> > inputs 5-7 to work. Inputs 5 and 6 don't have analog as a choice in
>>> > config-pin:
>>> >
>>> > $ config-pin -l P1_2
>>> > default gpio gpio_pu gpio_pd pruout pruin
>>> >
>>> > Analog input 7 (P2_36) doesn't have any other function, but it ignores
>>> any
>>> > analog input voltage.
>>> >
>>> > Is there a trick to using inputs 5-7 or is support under development?
>>>
>>> Since 5-7 ADC's are shared with a normal pin, you need to stick the
>>> gpio in gpio mode with config-pin.. (no pull-up, no pull-down) then it
>>> might work..
>>>
>>> Haven't personally tried this yet..
>>>
>>
>> I tested all 3 inputs as part of the board bring-up/validation process,
>> but I was using a different device tree. I'm trying to get back to it with
>> what Robert ships in the latest images, hopefully in the next day or so,
>> but I'd like to provide some notes that might be of some use:
>>
>> For 5 and 6, yeah, Robert's right on making sure the GPIO is set to input
>> mode (should be default?) and that there is no pull-up/pull-down enabled on
>> the pin. Do note, however, that there is a 10k pull-down due to the
>> resistor divider on the input. All voltages on the ADC will be half of what
>> they are on the headerpin.
>>
>> For 7, there is an analog mux, but it should default to the status of the
>> pin. There are some voltages internal to the PMIC that could be read, put
>> the header pin status should be the default.
>>
>>
>
>>> 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...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYjKoCF5-ZULWhZUdefCMZo84H1g_1tmPQjaUFOO4v8Xpg%40mail.gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> https://beagleboard.org/about
>>
> --
> 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/8a366e68-aa6f-4847-9a14-d2abb782d351%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
https://beagleboard.org/about

-- 
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

Re: [beagleboard] How to use PocketBeagle analog inputs 5-7?

2017-12-05 Thread Ken Shirriff 
Thanks Robert and Jason. For pin 5 and 6, your solution works:

Pin 5:
$ config-pin P2_35 gpio
$ echo in > /sys/class/gpio/gpio86/direction
$ cat /sys/bus/iio/devices/iio:device0/in_voltage5_raw
1571

Pin 6:
$ config-pin P1_2 gpio
$ echo in > /sys/class/gpio/gpio87/direction
$ cat /sys/bus/iio/devices/iio:device0/in_voltage6_raw
1571

Because of the voltage divider, the values are half of the "normal" values.

But I still can't get pin 7 to work:
$ while [ 1 ]; do cat /sys/bus/iio/devices/iio:device0/in_voltage7_raw; done
This gives me a sequence of values starting around 1600 dropping by about 
10 every second, unrelated to my input, slowing down to about 658. Sort of 
like the voltage if you were discharging a capacitor.

So analog input 7 seems to be measuring something, but I don't know what. 
Maybe some PMIC thing?

(I'm using Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 
2017 armv7l GNU/Linux)

Ken


On Tuesday, December 5, 2017 at 10:03:06 AM UTC-8, Jason Kridner wrote:
>
>
>
> On Tue, Dec 5, 2017 at 10:00 AM Robert Nelson  > wrote:
>
>> On Sun, Dec 3, 2017 at 1:07 PM, Ken Shirriff > > wrote:
>> > I can read analog inputs 0-4 from
>> > /sys/bus/iio/devices/iio:device0/in_voltageN_raw but I can't get analog
>> > inputs 5-7 to work. Inputs 5 and 6 don't have analog as a choice in
>> > config-pin:
>> >
>> > $ config-pin -l P1_2
>> > default gpio gpio_pu gpio_pd pruout pruin
>> >
>> > Analog input 7 (P2_36) doesn't have any other function, but it ignores 
>> any
>> > analog input voltage.
>> >
>> > Is there a trick to using inputs 5-7 or is support under development?
>>
>> Since 5-7 ADC's are shared with a normal pin, you need to stick the
>> gpio in gpio mode with config-pin.. (no pull-up, no pull-down) then it
>> might work..
>>
>> Haven't personally tried this yet..
>>
>
> I tested all 3 inputs as part of the board bring-up/validation process, 
> but I was using a different device tree. I'm trying to get back to it with 
> what Robert ships in the latest images, hopefully in the next day or so, 
> but I'd like to provide some notes that might be of some use:
>
> For 5 and 6, yeah, Robert's right on making sure the GPIO is set to input 
> mode (should be default?) and that there is no pull-up/pull-down enabled on 
> the pin. Do note, however, that there is a 10k pull-down due to the 
> resistor divider on the input. All voltages on the ADC will be half of what 
> they are on the headerpin.
>
> For 7, there is an analog mux, but it should default to the status of the 
> pin. There are some voltages internal to the PMIC that could be read, put 
> the header pin status should be the default.
>  
>
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYjKoCF5-ZULWhZUdefCMZo84H1g_1tmPQjaUFOO4v8Xpg%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> https://beagleboard.org/about
>

-- 
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/8a366e68-aa6f-4847-9a14-d2abb782d351%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: fsck fails to start on writable partition at boot/startup

2017-12-05 Thread Dave Barndt 
Hi Gautam,

Thanks for the reply! I actually had the same idea last night, and did 
manage to boot the board using an image on an SD card, and was able to run 
the fsck from there against the bad partition on the eMMC, and saw the 
details of the corruption. I was able to repair the partition and 
ultimately reflashed the board. So thanks for the reply and the 
confirmation!

But, what I'm still baffled about is: *Why the fsck couldn't run as part of 
the kernel startup when the system was booted normally?* I assume the 
partition hasn't been mounted at that point yet, so why would the fsck fail 
to start? It's really just more of an understanding-type of question.

Anyway, we 're now looking at ways to prevent sudden or unexpected power 
downs from potentially effecting such behavior/corruptions. Found this 
reference which looks pretty helpful: 
https://www.embeddedarm.com/about/resource/preventing-filesystem-corruption-in-embedded-linux
 
... and the BBB has power down signalling (section 5.10 of the ref manual) 
that we take advantage of as well.

Thanks again!

Dave

-- 
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/6a1b5c18-d05e-40ac-bfbe-4c0e30249d1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to use PocketBeagle analog inputs 5-7?

2017-12-05 Thread Jason Kridner 
On Tue, Dec 5, 2017 at 10:00 AM Robert Nelson 
wrote:

> On Sun, Dec 3, 2017 at 1:07 PM, Ken Shirriff 
> wrote:
> > I can read analog inputs 0-4 from
> > /sys/bus/iio/devices/iio:device0/in_voltageN_raw but I can't get analog
> > inputs 5-7 to work. Inputs 5 and 6 don't have analog as a choice in
> > config-pin:
> >
> > $ config-pin -l P1_2
> > default gpio gpio_pu gpio_pd pruout pruin
> >
> > Analog input 7 (P2_36) doesn't have any other function, but it ignores
> any
> > analog input voltage.
> >
> > Is there a trick to using inputs 5-7 or is support under development?
>
> Since 5-7 ADC's are shared with a normal pin, you need to stick the
> gpio in gpio mode with config-pin.. (no pull-up, no pull-down) then it
> might work..
>
> Haven't personally tried this yet..
>

I tested all 3 inputs as part of the board bring-up/validation process, but
I was using a different device tree. I'm trying to get back to it with what
Robert ships in the latest images, hopefully in the next day or so, but I'd
like to provide some notes that might be of some use:

For 5 and 6, yeah, Robert's right on making sure the GPIO is set to input
mode (should be default?) and that there is no pull-up/pull-down enabled on
the pin. Do note, however, that there is a 10k pull-down due to the
resistor divider on the input. All voltages on the ADC will be half of what
they are on the headerpin.

For 7, there is an analog mux, but it should default to the status of the
pin. There are some voltages internal to the PMIC that could be read, put
the header pin status should be the default.


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

-- 
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/CA%2BT6QP%3DBLZtnHiRnGfTT9Fvf0tG-x9-%3DgKYBffvxFYK3u-1R1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling CAN0 - "invalid mode: can"

2017-12-05 Thread Josh S 
debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
eeprom:[A335PBGL00A21744GPB20719]
dogtag:[BeagleBoard.org Debian Image 2017-10-10]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2017.09-2-g0f3f1c7907]
kernel:[4.4.91-ti-r133]
nodejs:[v6.11.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
debian@beaglebone:~$



On Tue, Dec 5, 2017 at 8:43 AM, Robert Nelson 
wrote:

> On Mon, Dec 4, 2017 at 9:10 PM,   wrote:
> > Wondering how to change the mode of P1_28 to CAN0RX and P1_26 to CAN0TX
> as
> > shown in the wiki:
> >
> > https://github.com/beagleboard/pocketbeagle/wiki/Peripherals#can
> >
> > It doesn't appear as though CAN is an option for those pins?
> >
> > ---
> > debian@beaglebone:/$ config-pin P1_28 can
> > Invalid mode: can
> > debian@beaglebone:/$ config-pin -l P1_28
> > default gpio gpio_pu gpio_pd spi i2c pru_uart
> > debian@beaglebone:/$ config-pin -l P1_26
> > default gpio gpio_pu gpio_pd spi i2c pru_uart
> > debian@beaglebone:/$
> >
> > ---
> >
> > Apologies if this is covered somewhere, I am still getting up to speed on
> > this cool little board. Thanks in advance!
>
>
> sudo /opt/scripts/tools/version.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/CAFLypv%3D11TS45ctYBVFotV1gWzbnowYOgqN%2BXgnaShh2Em9MBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling CAN0 - "invalid mode: can"

2017-12-05 Thread Josh S 
Thanks Robert! Got everything working on Can0!  Attached is a screen
capture of some data. Thanks again for your help.

On Tue, Dec 5, 2017 at 9:57 AM, Robert Nelson 
wrote:

> On Tue, Dec 5, 2017 at 9:43 AM, Josh S  wrote:
> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
> > git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
> > eeprom:[A335PBGL00A21744GPB20719]
> > dogtag:[BeagleBoard.org Debian Image 2017-10-10]
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> > 2017.09-2-g0f3f1c7907]
> > kernel:[4.4.91-ti-r133]
>
> can0/1 got enabled in r135
>
> > nodejs:[v6.11.4]
> > uboot_overlay_options:[enable_uboot_overlays=1]
> > uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/
> AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
> > uboot_overlay_options:[enable_uboot_cape_universal=1]
> > pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009]
>
> you'll also need to update bb-cape-overlays package:
>
> So just run:
>
> sudo apt update ; sudo apt upgrade
> sudo /opt/scripts/tools/update_kernel.sh
> sudo 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/CAFLypvmEo%2BHNWJtM%3D3BOn8-9e1Am%2BtNdTeyhOzYfP_HJwnEyOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling CAN0 - "invalid mode: can"

2017-12-05 Thread Robert Nelson 
On Tue, Dec 5, 2017 at 9:43 AM, Josh S  wrote:
> debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
> git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
> eeprom:[A335PBGL00A21744GPB20719]
> dogtag:[BeagleBoard.org Debian Image 2017-10-10]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> 2017.09-2-g0f3f1c7907]
> kernel:[4.4.91-ti-r133]

can0/1 got enabled in r135

> nodejs:[v6.11.4]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009]

you'll also need to update bb-cape-overlays package:

So just run:

sudo apt update ; sudo apt upgrade
sudo /opt/scripts/tools/update_kernel.sh
sudo 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/CAOCHtYh_UjrAiYmOg8V_GjK_u08h6Z4HN4z_C8R%2BU-eehm9Mrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble disabling HDMI + EMMC overlays?

2017-12-05 Thread Robert Nelson 
On Tue, Dec 5, 2017 at 4:44 AM,   wrote:
> Hello, I have the same issue
>
> I've tried many combinations in the uEnv.txt file to disable my emmc, but
> all of the time I get.
>
> root@beaglebone:~# config-pin -a P8_4 in+
> bash: /sys/devices/platform/ocp/ocp*P8_04_pinmux/state: No such file or
> directory
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P8_04_pinmux/state
>
>
> in dmesg:
> [   37.905449] bone-pinmux-helper ocp:P8_04_pinmux: Error applying setting,
> reverse things back
> [   37.938495] pinctrl-single 44e10800.pinmux: pin 44e1081c.0 already
> requested by 481d8000.mmc; cannot claim for ocp:P8_04_pinmux
> [   37.950240] pinctrl-single 44e10800.pinmux: pin-7 (ocp:P8_04_pinmux)
> status -22
> [   37.957691] pinctrl-single 44e10800.pinmux: could not request pin 7
> (44e1081c.0) from group pinmux_P8_04_default_pin  on device pinctrl-single
> [   37.970584] bone-pinmux-helper ocp:P8_04_pinmux: Error applying setting,
> reverse things back
> [   37.979109] bone-pinmux-helper ocp:P8_04_pinmux: Failed to select default
> state
>
> in slots:
>
> root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universala
>
>
> some info:
> Debian Jessie, running on a BeagleBone Green
>
> root@beaglebone:~# cat /etc/dogtag
> BeagleBoard.org Debian Image 2017-10-10
> root@beaglebone:~# uname -na
> Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l
> GNU/Linux
>
>
>
> If someone can give me some help, I'd really appreciate this!
> thanks!


sudo /opt/scripts/tools/version.sh


https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

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/CAOCHtYgAWJ8JWgAK8dof3m%3D-%2Bg-VNZMJNWFr3dK5NQsypPJmmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] why use AWS Cloud9?

2017-12-05 Thread Robert Nelson 
On Tue, Dec 5, 2017 at 9:14 AM, Ahmed  wrote:
> Hi,
>
> I am new to using the Beaglebone. I opened Cloud9 IDE on my beagebone and I
> wanted to create an account so I clicked on the Robot icon on the top right
> corner on the screen and I pressed on account. It took me to a login page
> only for previously registered users and for new users they have to use the
> AWS Cloud9 version.
>
> I have an AWS account so I started following through the steps without
> thinking what my goal was at first, which is to create a c9.io account. Now
> I would like to ask, why do I need to use AWS Cloud9 if I already have
> Cloud9 running on my Beagebone? What are the advantages and disadvantages?

You don't..

Amazon bought Cloud9 a few years back..

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

[beagleboard] why use AWS Cloud9?

2017-12-05 Thread Ahmed 
Hi,

I am new to using the Beaglebone. I opened Cloud9 IDE on my beagebone and I 
wanted to create an account so I clicked on the Robot icon on the top right 
corner on the screen and I pressed on account. It took me to a login page 
only for previously registered users and for new users they have to use the 
AWS Cloud9 version.

I have an AWS account so I started following through the steps without 
thinking what my goal was at first, which is to create a c9.io account. Now 
I would like to ask, why do I need to use AWS Cloud9 if I already have 
Cloud9 running on my Beagebone? What are the advantages and disadvantages?

Thank you

-- 
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/50f682ea-b52a-42f1-9ed7-bd7f847eae9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beagle Bone Power off Automatically After Some time.

2017-12-05 Thread Kartik Jagtap 
Hi 
I am using BeagleBone Black it has an Angstrom in it.
I power it from Barrel Jack,whenever i gives power to BB it start normally.
But after sometime USR led blink fast than normal and BeagleBone Off 
automatically.
I am using Cape also.

-- 
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/f78517f3-1c95-4408-8e52-186d31073951%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble disabling HDMI + EMMC overlays?

2017-12-05 Thread deeler 
Hello, I have the same issue

I've tried many combinations in the uEnv.txt file to disable my emmc, but 
all of the time I get.

root@beaglebone:~# config-pin -a P8_4 in+
bash: /sys/devices/platform/ocp/ocp*P8_04_pinmux/state: No such file or 
directory
Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P8_04_pinmux/state


in dmesg:
[   37.905449] bone-pinmux-helper ocp:P8_04_pinmux: Error applying setting, 
reverse things back
[   37.938495] pinctrl-single 44e10800.pinmux: pin 44e1081c.0 already 
requested by 481d8000.mmc; cannot claim for ocp:P8_04_pinmux
[   37.950240] pinctrl-single 44e10800.pinmux: pin-7 (ocp:P8_04_pinmux) 
status -22
[   37.957691] pinctrl-single 44e10800.pinmux: could not request pin 7 (
44e1081c.0) from group pinmux_P8_04_default_pin  on device pinctrl-single
[   37.970584] bone-pinmux-helper ocp:P8_04_pinmux: Error applying setting, 
reverse things back
[   37.979109] bone-pinmux-helper ocp:P8_04_pinmux: Failed to select default 
state

in slots:

root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universala


some info:
Debian Jessie, running on a BeagleBone Green

root@beaglebone:~# cat /etc/dogtag
BeagleBoard.org Debian Image 2017-10-10
root@beaglebone:~# uname -na
Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l 
GNU/Linux



If someone can give me some help, I'd really appreciate this!
thanks!







-- 
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/4ca64cca-fe27-44b0-b603-fb1ed41a36b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to use PocketBeagle analog inputs 5-7?

2017-12-05 Thread Robert Nelson 
On Sun, Dec 3, 2017 at 1:07 PM, Ken Shirriff  wrote:
> I can read analog inputs 0-4 from
> /sys/bus/iio/devices/iio:device0/in_voltageN_raw but I can't get analog
> inputs 5-7 to work. Inputs 5 and 6 don't have analog as a choice in
> config-pin:
>
> $ config-pin -l P1_2
> default gpio gpio_pu gpio_pd pruout pruin
>
> Analog input 7 (P2_36) doesn't have any other function, but it ignores any
> analog input voltage.
>
> Is there a trick to using inputs 5-7 or is support under development?

Since 5-7 ADC's are shared with a normal pin, you need to stick the
gpio in gpio mode with config-pin.. (no pull-up, no pull-down) then it
might work..

Haven't personally tried this yet..

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

Re: [beagleboard] 4DCAPE-70T + SGX EGLFS

2017-12-05 Thread Robert Nelson 
On Mon, Dec 4, 2017 at 8:22 PM,   wrote:
> I'm trying to build a system that supports SGX + EGLFS on a 4DCAPE-70T.
>
> The directions at http://vanguardiasur.com.ar/opengl-es-on-beaglebone-black/
> get me SGX + EGLFS with a TI v4.1.6 kernel, but without support for the
> 4DCAPE-70T.
>
> The directions at
> https://groups.google.com/d/msg/beagleboard/hG1JiS40o6U/a-f3M62HGLwJ looks
> like they'll get me very close to what I want with a TI 3.14 kernel, and I
> can see that RobertCNelson has a bunch of handy device tree files supporting
> the 4DCAPE-70T.
>
> However, I'm not sure how to apply the am335x-boneblack-4dcape-70t.dts to my
> build. Hopefully that's a simple task?

We use U-Boot Overlays now..

That guide uses Buildroot, so you'll need to do some work:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD7-01-00A3.dts

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

Re: [beagleboard] Re: Debian Testing (2017-04-30) U-Boot Overlays are now enabled by Default

2017-12-05 Thread Robert Nelson 
On Mon, Dec 4, 2017 at 7:31 PM,   wrote:
> Can someone tell me why I can blink LED_RED on the Beaglebone Blue (P8_7),
> but when I try the same thing in Bonescript I get:
>
> ocp:P8_07_pinmux was not found under /sys/devices/platform/ocp

LED is a different sub-system..

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

Re: [beagleboard] Enabling CAN0 - "invalid mode: can"

2017-12-05 Thread Robert Nelson 
On Mon, Dec 4, 2017 at 9:10 PM,   wrote:
> Wondering how to change the mode of P1_28 to CAN0RX and P1_26 to CAN0TX as
> shown in the wiki:
>
> https://github.com/beagleboard/pocketbeagle/wiki/Peripherals#can
>
> It doesn't appear as though CAN is an option for those pins?
>
> ---
> debian@beaglebone:/$ config-pin P1_28 can
> Invalid mode: can
> debian@beaglebone:/$ config-pin -l P1_28
> default gpio gpio_pu gpio_pd spi i2c pru_uart
> debian@beaglebone:/$ config-pin -l P1_26
> default gpio gpio_pu gpio_pd spi i2c pru_uart
> debian@beaglebone:/$
>
> ---
>
> Apologies if this is covered somewhere, I am still getting up to speed on
> this cool little board. Thanks in advance!


sudo /opt/scripts/tools/version.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/CAOCHtYhFn3v8BJdX98TS6422BZ9ijowULcLU5QpaBfgersRDmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: fsck fails to start on writable partition at boot/startup

2017-12-05 Thread mindentropy 


On Tuesday, December 5, 2017 at 3:00:32 AM UTC+5:30, Dave Barndt wrote:
>
> Hi,
>
> I'm hoping that someone has come across this problem before and can point 
> me in the right direction.
>
> I'm trying to troubleshoot a BeagleBone Black with Debian 8 that appears 
> to have a filesystem corruption. The system has two partitions, a read-only 
> rootfs partition and a writable partition for essentially everything else. 
> When the system boots, U-Boot completes and hands control to the kernel, 
> which runs an fsck on the rootfs successfully, but then fails to run an 
> fsck on the writable parition. At that point the startup process appears to 
> simply hang. I cannot seem to break to a console prompt (or get to a login 
> prompt, obviously).
>
> The best hypothesis I have so far is that some sort of power failure 
> caused a corruption, but I'd like to see if I can examine the "footprint" 
> at all. I've never seen a corruption where fsck can't be run at all. 
> Usually fsck can be run and the corruption can be examined and hopefully 
> repaired.
>
> My question is, why can't fsck be run on the partition at all? Can I 
> somehow break to the console prompt when the startup process hangs up? 
> Earlier in the process, I can interrupt U-Boot and run "mmc", "part", and 
> "ls" types of U-Boot commands to look at the partition in question - at 
> that level things appear to look OK. But obviously it can't tell why fsck 
> won't run on the partition.
>
> Could there be anything else going on that I'm not thinking of?
>
> Below is a log of the boot/startup process. Any light anyone can shed 
> would be very helpful.
>
> Thanks for any help,
> Dave
> ---
>
> U-Boot SPL 2016.11-2-gab8be1c (Dec 07 2016 - 12:54:09)
> Trying to boot from MMC2
>
>
> U-Boot 2016.11-2-gab8be1c (Dec 07 2016 - 12:54:09 -0600), Build: 
> jenkins-github_Bootloader-Builder-490
>
> CPU  : AM335X-GP rev 2.1
> I2C:   ready
> DRAM:  512 MiB
> Reset Source: Power-on reset has occurred.
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
>
> Board: BeagleBone Black
>  not set. Validating first E-fuse MAC
> Net:   eth0: MII MODE
> cpsw
> Press SPACE to abort autoboot in 2 seconds
> board_name=[A335BNLT] ...
> board_rev=[AIA0] ...
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> 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
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> switch to partitions #0, OK
> mmc1(part 0) is current device
> Scanning mmc 1: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
> mmc1(part 0) is current device
> gpio: pin 54 (gpio 54) value is 1
> Checking for: /uEnv.txt ...
> Checking for: /boot.scr ...
> Checking for: /boot/boot.scr ...
> Checking for: /boot/uEnv.txt ...
> gpio: pin 55 (gpio 55) value is 1
> 1388 bytes read in 28 ms (47.9 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt...
> gpio: pin 56 (gpio 56) value is 1
> Running uname_boot ...
> loading /boot/vmlinuz-4.4.36-ti-r72 ...
> 8646448 bytes read in 589 ms (14 MiB/s)
> loading /boot/dtbs/4.4.36-ti-r72/am335x-abbbi.dtb ...
> 61725 bytes read in 39 ms (1.5 MiB/s)
> loading /boot/initrd.img-4.4.36-ti-r72 ...
> 5231183 bytes read in 369 ms (13.5 MiB/s)
> debug: [console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-UART5,BB-I2C1 
> root=UUID=936d3d70-c3c4-4d5b-bb06-2d6d680ae95d ro rootfstype=ext4 rootwait 
> coherent_pool=1M quiet net.ifnames=0 cape_universal=enable] ...
> debug: [bootz 0x8200 0x8808:4fd24f 0x8800] ...
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8fb02000, end 824f ... OK
>Loading Device Tree to 8faef000, end 8fb0111c ... OK
>
> Starting kernel ...
>
> [0.001350] clocksource_probe: no matching clocksources found
> [2.075156] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
> [2.259213] omap_voltage_late_init: Voltage driver support not added
> [2.270746] PM: Cannot get wkup_m3_ipc handle
> [2.382235] bone_capemgr bone_capemgr: slot #0: No cape found
> [2.426233] bone_capemgr bone_capemgr: slot #1: No cape found
> [2.470229] bone_capemgr bone_capemgr: slot #2: No cape found
> [2.514227] bone_capemgr bone_capemgr: slot #3: No cape found
> Loading, please wait...
> rootfs: clean, 78785/98304 files, 384993/393216 blocks
> [   12.471231] pinctrl-single 44e10800.pinmux: pin 44e108c0.0 already 
> requested by 481aa000.serial; cannot claim for 0-0039
> [   12.482304] pinctrl-single 44e10800.pinmux: pin-48 (0-0039) status -22
> [   12.488911] pinctrl-single 44e10800.pinmux: could not