Re: [beagleboard] What is the latest BBGW image?

2016-07-02 Thread Robert Nelson 
On Sat, Jul 2, 2016 at 10:11 PM, Stephane Charette
 wrote:
>>> cannot seem to find one. The most recent Ubuntu image I see is this:
>>>
>>>
>>> http://rcn-ee.net/rootfs/2016-06-09/flasher/BBB-eMMC-flasher-ubuntu-16.04-console-armhf-2016-06-09-2gb.img.xz
>>>
>>> But from the name, this image seems to be for the BBB, not BBGW.
>>
>>It'll work fine for the bbgw, it's really for anything with an eMMC..
>
>
> When I first tried it, I couldn't get the BBGW wifi working. Now that I've
> got it working with the BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb
> image, I'll try my luck again with the Ubuntu image, since Ubuntu is what I
> want to eventually run on these devices. If there is an extra trick or
> package needed to get wireless working with your latest Ubuntu image, kindly
> point me to it.

Install, "bb-wl18xx-firmware"...

should get it working.

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/CAOCHtYgQd%2BJz2-bw%3D5eFhrOGjKeTbkoENDWvy%2BO2nSDoiQyx2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] What is the latest BBGW image?

2016-07-02 Thread Stephane Charette 
>> cannot seem to find one. The most recent Ubuntu image I see is this: 
>> 
>> 
http://rcn-ee.net/rootfs/2016-06-09/flasher/BBB-eMMC-flasher-ubuntu-16.04-console-armhf-2016-06-09-2gb.img.xz
 
>> 
>> But from the name, this image seems to be for the BBB, not BBGW. 
>
>It'll work fine for the bbgw, it's really for anything with an eMMC.. 


When I first tried it, I couldn't get the BBGW wifi working. Now that I've 
got it working with the 
BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb image, I'll try my 
luck again with the Ubuntu image, since Ubuntu is what I want to eventually 
run on these devices. If there is an extra trick or package needed to get 
wireless working with your latest Ubuntu image, kindly point me to it.

Thank you, Robert.

Stéphane

-- 
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/8461fb5a-318a-4719-9eaf-0946ffbc2721%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to disable SoftAp0 with address 192.168.8.1 on BBGW?

2016-07-02 Thread Robert Nelson 
On Sat, Jul 2, 2016 at 8:04 PM, Stephane Charette
 wrote:
> I'm running  BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb.img on a
> BBGW.  I've used connmanctl to configure the wifi network to which I want to
> connect, and everything is working OK so far.  On bootup, my BBGW does DHCP
> an address and I can ssh into it.
>
> What I'd like to do now is disable the SoftAp0 interface with the
> 192.168.8.1 address.  What is the correct/clean way to do this?
>
> If I run "sudo systemctl disable wificonfig.service", then wifi doesn't come
> up at all the next time I reboot.

SoftAp0 is created by the wifidog service:

wifidog-pre-startup.service
&
wifidog-gateway.service

https://github.com/rcn-ee/repos/blob/master/seeed-wificonfig-installer/suite/jessie/debian/wifidog_pre

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

Re: [beagleboard] What is the latest BBGW image?

2016-07-02 Thread Robert Nelson 
On Sat, Jul 2, 2016 at 1:54 PM, Stephane Charette
 wrote:
> Where would I find the most recent BBGW image?  Am I looking at the right
> place when I look at this:
>
> http://rcn-ee.net/rootfs/bb.org/testing/2016-06-19/seeed-iot/BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb.img.xz
>
> Related question:  where would the latest BBGW Ubuntu image be located?  I
> cannot seem to find one.  The most recent Ubuntu image I see is this:
>
> http://rcn-ee.net/rootfs/2016-06-09/flasher/BBB-eMMC-flasher-ubuntu-16.04-console-armhf-2016-06-09-2gb.img.xz
>
> But from the name, this image seems to be for the BBB, not BBGW.

It'll work fine for the bbgw, it's really for anything with an eMMC..

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/CAOCHtYgKMrYyAyic89iCNM%2BQEJFXdi%3DfEpSJvs-spRZx8UtG1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ddr3 length matching

2016-07-02 Thread larbi . joubala 
Ok thank you very much for the reply it is very useful.


Le jeudi 30 juin 2016 15:45:28 UTC+2, Wulf Man a écrit :
> http://referencedesigner.com/books/si/time-and-distance.php
> 
>   
> 
>   this can explain to you your issues
> 
>   
> 
>   
> 
>   
> 
>   On 6/30/2016 6:28 AM, Gerald Coley wrote:
> 
> 
> 
>   
> You use the PCB SW tools to give you the lengths of
> each trace. The distance from one layer to the next is not that
> significant and is well within the needed tolerance.
> 
> 
> 
> 
> 
> Gerald
> 
> 
> 
> 
>   
>   
> 
> 
> 
> On Sat, Jun 25, 2016 at 6:16 PM, 
>   wrote:
> 
>   Hello,
> 
> 
> 
>   I am designing my own board based on the am3358 and one
> ddr3 chip. I looked at the bbb project to have a example of
> layout and i have a question about length matching for the
> ddr3 interface. How the length matching has been done if
> different layers are used? The signal on the outer layers
> doesnt travel at the same speed as the inner layers.
> 
> 
> 
> --
> 
> 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/0f800b4e-6e8d-4e20-962d-7efb1d709ec2%40googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> Gerald
> 
>  
> 
> ger...@beagleboard.org
> 
> http://beagleboard.org/
> 
> gco...@emprodesign.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/CAHK_S%2Be0PNUqUP1v48RB0NYGMapggiESACpxC5-jg9uKH34HcA%40mail.gmail.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/4deed23e-febb-40c4-8790-3ad961d11a5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to disable SoftAp0 with address 192.168.8.1 on BBGW?

2016-07-02 Thread Stephane Charette 
I'm running  BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb.img on a 
BBGW.  I've used connmanctl to configure the wifi network to which I want 
to connect, and everything is working OK so far.  On bootup, my BBGW does 
DHCP an address and I can ssh into it.

What I'd like to do now is disable the SoftAp0 interface with the 
192.168.8.1 address.  What is the correct/clean way to do this?

If I run "sudo systemctl disable wificonfig.service", then wifi doesn't 
come up at all the next time I reboot.

-- 
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/6e3aaf3a-5b52-47e2-819b-78d73a32108b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU RPMsg device file missing

2016-07-02 Thread Greg 
Thank you Mark, I have updated my notes.

Greg

On Friday, July 1, 2016 at 10:39:47 AM UTC-4, Mark A. Yoder wrote:
>
> Greg:
>   Many thanks for your "guide".  I too have had success with it.  One 
> minor correction was needed:
>
>  cd /usr/share/ti/cgt-pru
>  mkdir bin
> * cd bin*
>  ln -s /usr/bin/clpru clpru
>
> The *cd bin* is needed to get clpru in the right place.
>
> --Mark
>
>
>>>

-- 
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/d2231c59-cd48-48ef-9188-fab88e339342%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] DS3234 clock on SPI1

2016-07-02 Thread William Hermans 
Additionally . . .

> dtb=am335x-boneblack-emmc-overlay.dtb
>
optargs=cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

Your optargs line is not longer required. Using the
am335x-boneblack-emmc-overlay.dtb board file disables hdmi video and audio
already.

> bone_capemgr bone_capemgr: slot #6: dtbo 'BB-SPI1CLK-00A0.dtbo' loaded;
overlay id #1

Your overlay seems to be loaded correctly.

One other thing caught my eye that I'm not sure is right or not. P9.28,
your CS pin, is active low ? Is that correct ? I was reading this:
http://www.sciencegizmo.com.au/?p=105 But if you look towards the bottom
for his device tree overlay for the rPI


*DS3234 Real Time Clock Bitbang Device Tree Overlay*
gpio-mosi = < 5 0>;
gpio-miso = < 6 0>;
gpio-sck = < 13 0>;
*cs-gpios = < 12 1>;*

He has the CS / CE line as active high. So perhaps a moot point, but it
caught my eye.

> quid ~ # hwclock -f /dev/rtc1 -r
> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc1 to read the time failed: Invalid
argument

The only time I've personally seen this hwclock error is when I attempt to
use a non rtc0 (  -> /dev/rtc ) clock without being root. e.g. $ sudo
hwclock -r -rtc /dev/rtc1 <--- not run as root user, so will fail with
default file permissions. But I'm also using an ds3232( I2C ).

Did you double check to make sure the rtc-ds3234 module was loaded via
lsmod ?

On Sat, Jul 2, 2016 at 3:01 PM, William Hermans  wrote:

> Ok, sorry scratch all the above. I remember Robert saying a few days ago
> that SPI must be loaded early at boot in order for it to work correctly.
> Some kind of glitch. Read teh last post here:
> https://groups.google.com/forum/#!searchin/beagleboard/SPI$20Robert|sort:date/beagleboard/vCFU_NWRdgo/7QGgua-QCgAJ
>
> On Sat, Jul 2, 2016 at 2:47 PM, William Hermans  wrote:
>
>> cs-gpios = < 17 0>;  /* Is this needed ??? */
>>
>> Double check your pin here make sure it's right. Someone was just saying
>> yesterday that the GPIO banks got restructured, and some address got
>> switched around. So it is entirely possible the pin you're after is no
>> longer on GPIO3 gpio bank.
>>
>> On Sat, Jul 2, 2016 at 2:33 PM, William Hermans 
>> wrote:
>>
>>> Additionally. You did set the time on the RTC before trying to read from
>>> it ?
>>>
>>> On Sat, Jul 2, 2016 at 2:26 PM, William Hermans 
>>> wrote:
>>>
 Have you updated the device tree compiler ? Here, I'm assuming you
 simply upgraded the kernel form an image that initially had 3.8.x installed
 . . .


 http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

 On Sat, Jul 2, 2016 at 2:08 PM,  wrote:

>
> Running kernel 4.4 and trying to read a DS3234 clock on the second SPI
> port I can suppress the HDMI pins in uEnv.txt with:
>
> dtb=am335x-boneblack-emmc-overlay.dtb
>
> optargs=cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
> (uEnv.txt isn't loading the "universal overlay".)
>
> Loading BB-SPIDEV0 and BB-SPI1CLK then produces the expected
> /dev/spidev1.0,
> /dev/spidev1.1 and /dev/rtc1 devices.
>
> dmesg says:
> bone_capemgr bone_capemgr: part_number 'BB-SPI1CLK', version 'N/A'
> bone_capemgr bone_capemgr: slot #6: override
> bone_capemgr bone_capemgr: Using override eeprom data at slot 6
> bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override
> Manuf,BB-SPI1CLK'
> ds3234 spi2.0: Control Reg: 0x00
> ds3234 spi2.0: Ctrl/Stat Reg: 0x00
> ds3234 spi2.0: rtc core: registered ds3234 as rtc1
> bone_capemgr bone_capemgr: slot #6: dtbo 'BB-SPI1CLK-00A0.dtbo'
> loaded; overlay id #1
>
> However, there's no spi pingroup, and the relevant pins remain in mode
> 7
> not mode 3, and are unclaimed:
>
> pin 100 (44e10990.0) 0027 pinctrl-single
> pin 101 (44e10994.0) 0027 pinctrl-single
> pin 102 (44e10998.0) 0027 pinctrl-single
> pin 103 (44e1099c.0) 0027 pinctrl-single
>
> pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>
> and reading the clocks gives:
>
> quid ~ # hwclock -f /dev/rtc0 -r
> Sat Jul  2 21:00:10 2016  .954216 seconds
> quid ~ # hwclock -f /dev/rtc1 -r
> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc1 to read the time failed:
> Invalid argument
> quid ~ #
>
> The clock overlay worked in 3.8, and I _think_ I've updated it
> correctly for
> 4.4.  Can anyone spot what I've missed?
>
> /*
> ** Dallas DS3234 RTC SPI driver test.
>

Re: [beagleboard] DS3234 clock on SPI1

2016-07-02 Thread William Hermans 
Ok, sorry scratch all the above. I remember Robert saying a few days ago
that SPI must be loaded early at boot in order for it to work correctly.
Some kind of glitch. Read teh last post here:
https://groups.google.com/forum/#!searchin/beagleboard/SPI$20Robert|sort:date/beagleboard/vCFU_NWRdgo/7QGgua-QCgAJ

On Sat, Jul 2, 2016 at 2:47 PM, William Hermans  wrote:

> cs-gpios = < 17 0>;  /* Is this needed ??? */
>
> Double check your pin here make sure it's right. Someone was just saying
> yesterday that the GPIO banks got restructured, and some address got
> switched around. So it is entirely possible the pin you're after is no
> longer on GPIO3 gpio bank.
>
> On Sat, Jul 2, 2016 at 2:33 PM, William Hermans  wrote:
>
>> Additionally. You did set the time on the RTC before trying to read from
>> it ?
>>
>> On Sat, Jul 2, 2016 at 2:26 PM, William Hermans 
>> wrote:
>>
>>> Have you updated the device tree compiler ? Here, I'm assuming you
>>> simply upgraded the kernel form an image that initially had 3.8.x installed
>>> . . .
>>>
>>>
>>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>>
>>> On Sat, Jul 2, 2016 at 2:08 PM,  wrote:
>>>

 Running kernel 4.4 and trying to read a DS3234 clock on the second SPI
 port I can suppress the HDMI pins in uEnv.txt with:

 dtb=am335x-boneblack-emmc-overlay.dtb

 optargs=cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

 (uEnv.txt isn't loading the "universal overlay".)

 Loading BB-SPIDEV0 and BB-SPI1CLK then produces the expected
 /dev/spidev1.0,
 /dev/spidev1.1 and /dev/rtc1 devices.

 dmesg says:
 bone_capemgr bone_capemgr: part_number 'BB-SPI1CLK', version 'N/A'
 bone_capemgr bone_capemgr: slot #6: override
 bone_capemgr bone_capemgr: Using override eeprom data at slot 6
 bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override
 Manuf,BB-SPI1CLK'
 ds3234 spi2.0: Control Reg: 0x00
 ds3234 spi2.0: Ctrl/Stat Reg: 0x00
 ds3234 spi2.0: rtc core: registered ds3234 as rtc1
 bone_capemgr bone_capemgr: slot #6: dtbo 'BB-SPI1CLK-00A0.dtbo' loaded;
 overlay id #1

 However, there's no spi pingroup, and the relevant pins remain in mode 7
 not mode 3, and are unclaimed:

 pin 100 (44e10990.0) 0027 pinctrl-single
 pin 101 (44e10994.0) 0027 pinctrl-single
 pin 102 (44e10998.0) 0027 pinctrl-single
 pin 103 (44e1099c.0) 0027 pinctrl-single

 pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
 pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
 pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
 pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)

 and reading the clocks gives:

 quid ~ # hwclock -f /dev/rtc0 -r
 Sat Jul  2 21:00:10 2016  .954216 seconds
 quid ~ # hwclock -f /dev/rtc1 -r
 hwclock: ioctl(RTC_RD_TIME) to /dev/rtc1 to read the time failed:
 Invalid argument
 quid ~ #

 The clock overlay worked in 3.8, and I _think_ I've updated it
 correctly for
 4.4.  Can anyone spot what I've missed?

 /*
 ** Dallas DS3234 RTC SPI driver test.
 **
 ** Virtual cape for SPI1 on connector pins P9.29 P9.31 P9.30 P9.28
 **
 ** Pin Identities.
 **
 ** SPI_1 names : CS0,   DO,DI,CLK
 ** P9 pins : 28,29,30,31
 ** GPIO3 pins  : 17,15,16,14
 ** Processor pins  : C12,   B13,   D12,   A13
 ** SRM table 15 ?? : 214,   210,   212,   218
 ** Pingroup labels : 103,   101,   ???100
 ** Code offsets: 0x19c, 0x194, 0x198, 0x190
 ** Base pin gpmc_ad0 has address 0x800 giving:
 ** : 0x99c, 0x994, 0x998, 0x990
 ** TRM 9.3 (spi0)  : 0x95c, 0x954, 0x958, 0x950
 **
 ** Moved to kernel 4.x GPIO bank numbering.
 */

 /dts-v1/;
 /plugin/;

 / {
 compatible = "ti,beaglebone", "ti,beaglebone-black";

 /* identification */
 part-number = "BB-SPI1CLK";
 version = "00A0";

 /* Resources */
 exclusive-use =
 /* Pin header */
 "P9.31",/* spi1_sclk */
 "P9.29",/* spi1_d0 */
 "P9.30",/* spi1_d1 */
 "P9.28",/* spi1_cs0 */
 /* Hardware */
 "spi1";

 fragment@0 {
 target = <_pinmux>;
 __overlay__ {
 /* Default has all gpios released, mode uart1 */
 pinctrl_spi1: pinctrl_spi1_pins {
 pinctrl-single,pins = <
 0x190 0x33 /* P9_31 = mcasp0_aclkx.spi1_sclk,
 INPUT_PULLUP | MODE3 */
 0x194 0x33 /* P9_29 = mcasp0_fsx.spi1_d0,
 INPUT_PULLUP  | MODE3 */
 0x198

Re: [beagleboard] DS3234 clock on SPI1

2016-07-02 Thread William Hermans 
cs-gpios = < 17 0>;  /* Is this needed ??? */

Double check your pin here make sure it's right. Someone was just saying
yesterday that the GPIO banks got restructured, and some address got
switched around. So it is entirely possible the pin you're after is no
longer on GPIO3 gpio bank.

On Sat, Jul 2, 2016 at 2:33 PM, William Hermans  wrote:

> Additionally. You did set the time on the RTC before trying to read from
> it ?
>
> On Sat, Jul 2, 2016 at 2:26 PM, William Hermans  wrote:
>
>> Have you updated the device tree compiler ? Here, I'm assuming you simply
>> upgraded the kernel form an image that initially had 3.8.x installed . . .
>>
>>
>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>
>> On Sat, Jul 2, 2016 at 2:08 PM,  wrote:
>>
>>>
>>> Running kernel 4.4 and trying to read a DS3234 clock on the second SPI
>>> port I can suppress the HDMI pins in uEnv.txt with:
>>>
>>> dtb=am335x-boneblack-emmc-overlay.dtb
>>>
>>> optargs=cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>>>
>>> (uEnv.txt isn't loading the "universal overlay".)
>>>
>>> Loading BB-SPIDEV0 and BB-SPI1CLK then produces the expected
>>> /dev/spidev1.0,
>>> /dev/spidev1.1 and /dev/rtc1 devices.
>>>
>>> dmesg says:
>>> bone_capemgr bone_capemgr: part_number 'BB-SPI1CLK', version 'N/A'
>>> bone_capemgr bone_capemgr: slot #6: override
>>> bone_capemgr bone_capemgr: Using override eeprom data at slot 6
>>> bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override
>>> Manuf,BB-SPI1CLK'
>>> ds3234 spi2.0: Control Reg: 0x00
>>> ds3234 spi2.0: Ctrl/Stat Reg: 0x00
>>> ds3234 spi2.0: rtc core: registered ds3234 as rtc1
>>> bone_capemgr bone_capemgr: slot #6: dtbo 'BB-SPI1CLK-00A0.dtbo' loaded;
>>> overlay id #1
>>>
>>> However, there's no spi pingroup, and the relevant pins remain in mode 7
>>> not mode 3, and are unclaimed:
>>>
>>> pin 100 (44e10990.0) 0027 pinctrl-single
>>> pin 101 (44e10994.0) 0027 pinctrl-single
>>> pin 102 (44e10998.0) 0027 pinctrl-single
>>> pin 103 (44e1099c.0) 0027 pinctrl-single
>>>
>>> pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>>> pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>>> pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>>> pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>>>
>>> and reading the clocks gives:
>>>
>>> quid ~ # hwclock -f /dev/rtc0 -r
>>> Sat Jul  2 21:00:10 2016  .954216 seconds
>>> quid ~ # hwclock -f /dev/rtc1 -r
>>> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc1 to read the time failed:
>>> Invalid argument
>>> quid ~ #
>>>
>>> The clock overlay worked in 3.8, and I _think_ I've updated it correctly
>>> for
>>> 4.4.  Can anyone spot what I've missed?
>>>
>>> /*
>>> ** Dallas DS3234 RTC SPI driver test.
>>> **
>>> ** Virtual cape for SPI1 on connector pins P9.29 P9.31 P9.30 P9.28
>>> **
>>> ** Pin Identities.
>>> **
>>> ** SPI_1 names : CS0,   DO,DI,CLK
>>> ** P9 pins : 28,29,30,31
>>> ** GPIO3 pins  : 17,15,16,14
>>> ** Processor pins  : C12,   B13,   D12,   A13
>>> ** SRM table 15 ?? : 214,   210,   212,   218
>>> ** Pingroup labels : 103,   101,   ???100
>>> ** Code offsets: 0x19c, 0x194, 0x198, 0x190
>>> ** Base pin gpmc_ad0 has address 0x800 giving:
>>> ** : 0x99c, 0x994, 0x998, 0x990
>>> ** TRM 9.3 (spi0)  : 0x95c, 0x954, 0x958, 0x950
>>> **
>>> ** Moved to kernel 4.x GPIO bank numbering.
>>> */
>>>
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>
>>> /* identification */
>>> part-number = "BB-SPI1CLK";
>>> version = "00A0";
>>>
>>> /* Resources */
>>> exclusive-use =
>>> /* Pin header */
>>> "P9.31",/* spi1_sclk */
>>> "P9.29",/* spi1_d0 */
>>> "P9.30",/* spi1_d1 */
>>> "P9.28",/* spi1_cs0 */
>>> /* Hardware */
>>> "spi1";
>>>
>>> fragment@0 {
>>> target = <_pinmux>;
>>> __overlay__ {
>>> /* Default has all gpios released, mode uart1 */
>>> pinctrl_spi1: pinctrl_spi1_pins {
>>> pinctrl-single,pins = <
>>> 0x190 0x33 /* P9_31 = mcasp0_aclkx.spi1_sclk,
>>> INPUT_PULLUP | MODE3 */
>>> 0x194 0x33 /* P9_29 = mcasp0_fsx.spi1_d0,
>>> INPUT_PULLUP  | MODE3 */
>>> 0x198 0x13 /* P9_30 = mcasp0_axr0.spi1_d1,
>>> OUTPUT_PULLUP | MODE3 */
>>> 0x19c 0x13 /* P9_28 = mcasp0_ahclkr.spi1_cs0,
>>> OUTPUT_PULLUP | MODE3 */
>>> >;
>>> };
>>> };
>>> };
>>>
>>> fragment@1 {
>>> target = <>;
>>> __overlay__ {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> status   = "okay";
>>> pinctrl-names= "default";
>>> pinctrl-0= <_spi1>;
>>>

Re: [beagleboard] DS3234 clock on SPI1

2016-07-02 Thread William Hermans 
Additionally. You did set the time on the RTC before trying to read from it
?

On Sat, Jul 2, 2016 at 2:26 PM, William Hermans  wrote:

> Have you updated the device tree compiler ? Here, I'm assuming you simply
> upgraded the kernel form an image that initially had 3.8.x installed . . .
>
>
> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>
> On Sat, Jul 2, 2016 at 2:08 PM,  wrote:
>
>>
>> Running kernel 4.4 and trying to read a DS3234 clock on the second SPI
>> port I can suppress the HDMI pins in uEnv.txt with:
>>
>> dtb=am335x-boneblack-emmc-overlay.dtb
>>
>> optargs=cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>>
>> (uEnv.txt isn't loading the "universal overlay".)
>>
>> Loading BB-SPIDEV0 and BB-SPI1CLK then produces the expected
>> /dev/spidev1.0,
>> /dev/spidev1.1 and /dev/rtc1 devices.
>>
>> dmesg says:
>> bone_capemgr bone_capemgr: part_number 'BB-SPI1CLK', version 'N/A'
>> bone_capemgr bone_capemgr: slot #6: override
>> bone_capemgr bone_capemgr: Using override eeprom data at slot 6
>> bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override
>> Manuf,BB-SPI1CLK'
>> ds3234 spi2.0: Control Reg: 0x00
>> ds3234 spi2.0: Ctrl/Stat Reg: 0x00
>> ds3234 spi2.0: rtc core: registered ds3234 as rtc1
>> bone_capemgr bone_capemgr: slot #6: dtbo 'BB-SPI1CLK-00A0.dtbo' loaded;
>> overlay id #1
>>
>> However, there's no spi pingroup, and the relevant pins remain in mode 7
>> not mode 3, and are unclaimed:
>>
>> pin 100 (44e10990.0) 0027 pinctrl-single
>> pin 101 (44e10994.0) 0027 pinctrl-single
>> pin 102 (44e10998.0) 0027 pinctrl-single
>> pin 103 (44e1099c.0) 0027 pinctrl-single
>>
>> pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>> pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>> pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>> pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>>
>> and reading the clocks gives:
>>
>> quid ~ # hwclock -f /dev/rtc0 -r
>> Sat Jul  2 21:00:10 2016  .954216 seconds
>> quid ~ # hwclock -f /dev/rtc1 -r
>> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc1 to read the time failed: Invalid
>> argument
>> quid ~ #
>>
>> The clock overlay worked in 3.8, and I _think_ I've updated it correctly
>> for
>> 4.4.  Can anyone spot what I've missed?
>>
>> /*
>> ** Dallas DS3234 RTC SPI driver test.
>> **
>> ** Virtual cape for SPI1 on connector pins P9.29 P9.31 P9.30 P9.28
>> **
>> ** Pin Identities.
>> **
>> ** SPI_1 names : CS0,   DO,DI,CLK
>> ** P9 pins : 28,29,30,31
>> ** GPIO3 pins  : 17,15,16,14
>> ** Processor pins  : C12,   B13,   D12,   A13
>> ** SRM table 15 ?? : 214,   210,   212,   218
>> ** Pingroup labels : 103,   101,   ???100
>> ** Code offsets: 0x19c, 0x194, 0x198, 0x190
>> ** Base pin gpmc_ad0 has address 0x800 giving:
>> ** : 0x99c, 0x994, 0x998, 0x990
>> ** TRM 9.3 (spi0)  : 0x95c, 0x954, 0x958, 0x950
>> **
>> ** Moved to kernel 4.x GPIO bank numbering.
>> */
>>
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>
>> /* identification */
>> part-number = "BB-SPI1CLK";
>> version = "00A0";
>>
>> /* Resources */
>> exclusive-use =
>> /* Pin header */
>> "P9.31",/* spi1_sclk */
>> "P9.29",/* spi1_d0 */
>> "P9.30",/* spi1_d1 */
>> "P9.28",/* spi1_cs0 */
>> /* Hardware */
>> "spi1";
>>
>> fragment@0 {
>> target = <_pinmux>;
>> __overlay__ {
>> /* Default has all gpios released, mode uart1 */
>> pinctrl_spi1: pinctrl_spi1_pins {
>> pinctrl-single,pins = <
>> 0x190 0x33 /* P9_31 = mcasp0_aclkx.spi1_sclk,
>> INPUT_PULLUP | MODE3 */
>> 0x194 0x33 /* P9_29 = mcasp0_fsx.spi1_d0,
>> INPUT_PULLUP  | MODE3 */
>> 0x198 0x13 /* P9_30 = mcasp0_axr0.spi1_d1,
>> OUTPUT_PULLUP | MODE3 */
>> 0x19c 0x13 /* P9_28 = mcasp0_ahclkr.spi1_cs0,
>> OUTPUT_PULLUP | MODE3 */
>> >;
>> };
>> };
>> };
>>
>> fragment@1 {
>> target = <>;
>> __overlay__ {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> status   = "okay";
>> pinctrl-names= "default";
>> pinctrl-0= <_spi1>;
>> cs-gpios = < 17 0>;  /* Is this needed ??? */
>> ds3234@0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "ds3234";
>> reg = <0>;
>> spi-max-frequency = <20>; /* Slowed for testing */
>> /* spi-cpha ??? */
>> };
>> };
>> };
>>
>> };
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message

Re: [beagleboard] DS3234 clock on SPI1

2016-07-02 Thread William Hermans 
Have you updated the device tree compiler ? Here, I'm assuming you simply
upgraded the kernel form an image that initially had 3.8.x installed . . .

http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

On Sat, Jul 2, 2016 at 2:08 PM,  wrote:

>
> Running kernel 4.4 and trying to read a DS3234 clock on the second SPI
> port I can suppress the HDMI pins in uEnv.txt with:
>
> dtb=am335x-boneblack-emmc-overlay.dtb
>
> optargs=cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
> (uEnv.txt isn't loading the "universal overlay".)
>
> Loading BB-SPIDEV0 and BB-SPI1CLK then produces the expected
> /dev/spidev1.0,
> /dev/spidev1.1 and /dev/rtc1 devices.
>
> dmesg says:
> bone_capemgr bone_capemgr: part_number 'BB-SPI1CLK', version 'N/A'
> bone_capemgr bone_capemgr: slot #6: override
> bone_capemgr bone_capemgr: Using override eeprom data at slot 6
> bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override
> Manuf,BB-SPI1CLK'
> ds3234 spi2.0: Control Reg: 0x00
> ds3234 spi2.0: Ctrl/Stat Reg: 0x00
> ds3234 spi2.0: rtc core: registered ds3234 as rtc1
> bone_capemgr bone_capemgr: slot #6: dtbo 'BB-SPI1CLK-00A0.dtbo' loaded;
> overlay id #1
>
> However, there's no spi pingroup, and the relevant pins remain in mode 7
> not mode 3, and are unclaimed:
>
> pin 100 (44e10990.0) 0027 pinctrl-single
> pin 101 (44e10994.0) 0027 pinctrl-single
> pin 102 (44e10998.0) 0027 pinctrl-single
> pin 103 (44e1099c.0) 0027 pinctrl-single
>
> pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>
> and reading the clocks gives:
>
> quid ~ # hwclock -f /dev/rtc0 -r
> Sat Jul  2 21:00:10 2016  .954216 seconds
> quid ~ # hwclock -f /dev/rtc1 -r
> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc1 to read the time failed: Invalid
> argument
> quid ~ #
>
> The clock overlay worked in 3.8, and I _think_ I've updated it correctly
> for
> 4.4.  Can anyone spot what I've missed?
>
> /*
> ** Dallas DS3234 RTC SPI driver test.
> **
> ** Virtual cape for SPI1 on connector pins P9.29 P9.31 P9.30 P9.28
> **
> ** Pin Identities.
> **
> ** SPI_1 names : CS0,   DO,DI,CLK
> ** P9 pins : 28,29,30,31
> ** GPIO3 pins  : 17,15,16,14
> ** Processor pins  : C12,   B13,   D12,   A13
> ** SRM table 15 ?? : 214,   210,   212,   218
> ** Pingroup labels : 103,   101,   ???100
> ** Code offsets: 0x19c, 0x194, 0x198, 0x190
> ** Base pin gpmc_ad0 has address 0x800 giving:
> ** : 0x99c, 0x994, 0x998, 0x990
> ** TRM 9.3 (spi0)  : 0x95c, 0x954, 0x958, 0x950
> **
> ** Moved to kernel 4.x GPIO bank numbering.
> */
>
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "BB-SPI1CLK";
> version = "00A0";
>
> /* Resources */
> exclusive-use =
> /* Pin header */
> "P9.31",/* spi1_sclk */
> "P9.29",/* spi1_d0 */
> "P9.30",/* spi1_d1 */
> "P9.28",/* spi1_cs0 */
> /* Hardware */
> "spi1";
>
> fragment@0 {
> target = <_pinmux>;
> __overlay__ {
> /* Default has all gpios released, mode uart1 */
> pinctrl_spi1: pinctrl_spi1_pins {
> pinctrl-single,pins = <
> 0x190 0x33 /* P9_31 = mcasp0_aclkx.spi1_sclk,
> INPUT_PULLUP | MODE3 */
> 0x194 0x33 /* P9_29 = mcasp0_fsx.spi1_d0,
> INPUT_PULLUP  | MODE3 */
> 0x198 0x13 /* P9_30 = mcasp0_axr0.spi1_d1,
> OUTPUT_PULLUP | MODE3 */
> 0x19c 0x13 /* P9_28 = mcasp0_ahclkr.spi1_cs0,
> OUTPUT_PULLUP | MODE3 */
> >;
> };
> };
> };
>
> fragment@1 {
> target = <>;
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
> status   = "okay";
> pinctrl-names= "default";
> pinctrl-0= <_spi1>;
> cs-gpios = < 17 0>;  /* Is this needed ??? */
> ds3234@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "ds3234";
> reg = <0>;
> spi-max-frequency = <20>; /* Slowed for testing */
> /* spi-cpha ??? */
> };
> };
> };
>
> };
>
>
> --
> 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
>

[beagleboard] DS3234 clock on SPI1

2016-07-02 Thread cwrseckford 

Running kernel 4.4 and trying to read a DS3234 clock on the second SPI
port I can suppress the HDMI pins in uEnv.txt with:

dtb=am335x-boneblack-emmc-overlay.dtb
optargs=cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

(uEnv.txt isn't loading the "universal overlay".)

Loading BB-SPIDEV0 and BB-SPI1CLK then produces the expected /dev/spidev1.0,
/dev/spidev1.1 and /dev/rtc1 devices.

dmesg says:
bone_capemgr bone_capemgr: part_number 'BB-SPI1CLK', version 'N/A'
bone_capemgr bone_capemgr: slot #6: override
bone_capemgr bone_capemgr: Using override eeprom data at slot 6
bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override 
Manuf,BB-SPI1CLK'
ds3234 spi2.0: Control Reg: 0x00
ds3234 spi2.0: Ctrl/Stat Reg: 0x00
ds3234 spi2.0: rtc core: registered ds3234 as rtc1
bone_capemgr bone_capemgr: slot #6: dtbo 'BB-SPI1CLK-00A0.dtbo' loaded; 
overlay id #1

However, there's no spi pingroup, and the relevant pins remain in mode 7
not mode 3, and are unclaimed:

pin 100 (44e10990.0) 0027 pinctrl-single 
pin 101 (44e10994.0) 0027 pinctrl-single 
pin 102 (44e10998.0) 0027 pinctrl-single 
pin 103 (44e1099c.0) 0027 pinctrl-single 

pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)

and reading the clocks gives:

quid ~ # hwclock -f /dev/rtc0 -r
Sat Jul  2 21:00:10 2016  .954216 seconds
quid ~ # hwclock -f /dev/rtc1 -r
hwclock: ioctl(RTC_RD_TIME) to /dev/rtc1 to read the time failed: Invalid 
argument
quid ~ # 

The clock overlay worked in 3.8, and I _think_ I've updated it correctly for
4.4.  Can anyone spot what I've missed?

/*
** Dallas DS3234 RTC SPI driver test.
**
** Virtual cape for SPI1 on connector pins P9.29 P9.31 P9.30 P9.28
**
** Pin Identities.
**
** SPI_1 names : CS0,   DO,DI,CLK
** P9 pins : 28,29,30,31
** GPIO3 pins  : 17,15,16,14
** Processor pins  : C12,   B13,   D12,   A13
** SRM table 15 ?? : 214,   210,   212,   218
** Pingroup labels : 103,   101,   ???100
** Code offsets: 0x19c, 0x194, 0x198, 0x190
** Base pin gpmc_ad0 has address 0x800 giving:
** : 0x99c, 0x994, 0x998, 0x990
** TRM 9.3 (spi0)  : 0x95c, 0x954, 0x958, 0x950
**
** Moved to kernel 4.x GPIO bank numbering.
*/

/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */
part-number = "BB-SPI1CLK";
version = "00A0";

/* Resources */
exclusive-use =
/* Pin header */
"P9.31",/* spi1_sclk */
"P9.29",/* spi1_d0 */
"P9.30",/* spi1_d1 */
"P9.28",/* spi1_cs0 */
/* Hardware */
"spi1";

fragment@0 {
target = <_pinmux>;
__overlay__ {
/* Default has all gpios released, mode uart1 */
pinctrl_spi1: pinctrl_spi1_pins {
pinctrl-single,pins = <
0x190 0x33 /* P9_31 = mcasp0_aclkx.spi1_sclk, 
INPUT_PULLUP | MODE3 */
0x194 0x33 /* P9_29 = mcasp0_fsx.spi1_d0, INPUT_PULLUP  
| MODE3 */
0x198 0x13 /* P9_30 = mcasp0_axr0.spi1_d1, 
OUTPUT_PULLUP | MODE3 */
0x19c 0x13 /* P9_28 = mcasp0_ahclkr.spi1_cs0, 
OUTPUT_PULLUP | MODE3 */
>;
};
};
};

fragment@1 {
target = <>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
status   = "okay";
pinctrl-names= "default";
pinctrl-0= <_spi1>;
cs-gpios = < 17 0>;  /* Is this needed ??? */
ds3234@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ds3234";
reg = <0>;
spi-max-frequency = <20>; /* Slowed for testing */
/* spi-cpha ??? */
};
};
};

};


-- 
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/214a0cf1-6d1f-4b52-9335-7689dd8abb68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB startup current

2016-07-02 Thread Gerald Coley 
OF all the board we have shipped, we have never lost a TPS5217C due to this
issue. In fact, I think we have only lost maybe 5 TPS65217C devices total
in 4+ years.

And as i said, you have to charge up those caps. I am not sure how to
prevent caps from needing to be charged.

And as we also say, use a good power supply. That sometimes means not the
cheapest ones.

The makers of the Green are certainly free to add whatever they like to
their design.

.
Gerald

On Sat, Jul 2, 2016 at 8:26 AM,  wrote:

> Before I forgot.
>
> TPS not limit output capacitors, but recommend 22+10+10+10+10=62 uF. BBB
> use 100+10+10+10+10+10=140 uF. This is more than twice than recommended.
>
> Furthermore TPS recommend not only capacitance but ESR of capacitors too
> (as 20mOhm). This is determine start-up current too.
>
> BBB use C34 100uF as puffer to feed USB host connector. But it is not
> isolated from sys power line (need FBB?). Looks like this is where current
> peak originated from.
>
> TPS has soft start feature but only for DC-DC converters and LDOs.
> Therefore no soft start for capacitive load connected to SYS power line.
>
> It is advisable to add some part to SYS power line for further models
> (e.g. Green).
>
> But up to this moment I think it is recommended to use power supply with
> <=2.5A current limit to prevent damage of TPS. TPS has 3A absolute maximum
> current limit.
>
> --
> 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/5a139200-6034-4fd7-9885-db40303bb5a4%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.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/CAHK_S%2BfcXN1_kLZ3uzA04RjQYPopSoJjjype8vp9C77OJnuo%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] What is the latest BBGW image?

2016-07-02 Thread Stephane Charette 
Where would I find the most recent BBGW image?  Am I looking at the right 
place when I look at this:

http://rcn-ee.net/rootfs/bb.org/testing/2016-06-19/seeed-iot/BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb.img.xz

Related question:  where would the latest BBGW *Ubuntu* image be located? 
 I cannot seem to find one.  The most recent Ubuntu image I see is this:

http://rcn-ee.net/rootfs/2016-06-09/flasher/BBB-eMMC-flasher-ubuntu-16.04-console-armhf-2016-06-09-2gb.img.xz

But from the name, this image seems to be for the BBB, not BBGW.

Thanks for pointers!

-- 
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/2030c7af-cb68-44d9-83da-d8e66bab0d08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] beaglebone black pwm pin can't find duty, period, ...

2016-07-02 Thread Ray Madigan 
I am trying to use the pin P8_13 for pwm.  When I load the overlay I the 
power file is created but no duty, period, ... files are created.  I am 
clearly doing something wrong.  I can't use the universal overlay because I 
can't figure out how to load a one wire device in the universal overlay. 
 With the universal overlay the pwm works perfectly.  

I am using kernel 3.8.13-bone70

My overlay is as follows:

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */
part-number = "BREW_PWM_P8_13";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.13",
/* the hardware IP uses */
"ehrpwm2B";

fragment@0 {
target = <_pinmux>;
__overlay__ {
brew_pwm_P8_13: pinmux_brew_pwm_P8_13 {
pinctrl-single,pins = <0x024 0x24>;
};
};
};

fragment@1 {
target = <>;
__overlay__ {
brewery_pwm_P8_13 {
compatible  = "pwm_brew";
pwms= < 1 50 0>;
pwm-names   = "PWM_P8_13";
pinctrl-names   = "pwm";
pinctrl-0   = <_pwm_P8_13>;
enabled = <1>;
duty= <0>;
status  = "okay";
};
};
};
};

when I load the overlay dmesg shows the overlay was accepted

the directory for the pwm pin is created and it has 
modalias: a file
power: a directory
subsystem: a link
uevent: a file

I can't find the duty, period, ... files that are needed to control the pwm.

Any guidance would be appreciated.

-- 
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/436ed8be-8a43-4c05-8362-db54d0ecd28f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] initrd.img not detected

2016-07-02 Thread richatnstar via BeagleBoard 
Hi,

Per Robert Nelson's eewiki site, I have a running BBB running 
4.4.11-bone10.1 version (single partition model); 
*initrd.img-4.4.11-bone10.1* is in /boot. A previous version, 4.4.1-bone5, 
indicated that initramfs was installed (two partition model)---

[3.484281] Unpacking 
initramfs...
   

[3.821276] Freeing initrd memory: 5196K (c808 - 
c8593000)   

I don't see those lines now. uEnv.txt in root has  ...

"loadxrd=load mmc 0:1 ${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize 
${filesize}"

Diagnostics shows that the file is read into memory OK.

I sprinkled pr_debug() diagnostics in kernel to track progress -- in 
start_kernel(void) located in init/main.c
I added around line #625..

   locking_selftest();
   *pr_notice("initrd_start:%d  initrd_below_start_ok:%d\n", 
initrd_start, initrd_below_start_ok);*

Both initrd_start and initrd_below_start_ok were 0 ... should these value 
be >0? Am I missing a configuration parameter? Are there any
other areas in the kernel to track progress?


thx for any help


-- 
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/cefe47d0-f786-4472-a469-d67f6c1eb829%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Looking for recommendation for BBB cross-compile toolchain and IDE for Windows

2016-07-02 Thread ivbsd1 
Thanks for info.
I understand the mode of your work with BBB.


On Friday, July 1, 2016 at 10:06:48 PM UTC+3, William Hermans wrote:
>
>
> $ gcc somefile.c -o somefile -Wall/* and whatever other options I want 
>> and need */
>> $ chmod +x ./somefile/* File needs to be given executable 
>> permissions */
>> $ ./somefile/* Then the application does its 
>> thing . . .*/
>>
>
> For larger projects though when using multiple C / header files. Using 
> Make is probably a good idea.
>
> On Fri, Jul 1, 2016 at 12:02 PM, William Hermans  > wrote:
>
>> > William, 
>> >
>> > Thanks for input about using BBB itself.
>> > But I am worried about scalability of this solution. Software tends to 
>> grow very quickly. 
>>
>> What software tends to grow quickly ? You really need to think about what 
>> you're doing. But if you're writing all the code yourself, and maybe using 
>> some form of a Linux libc, and / or standard Linux API calls. You program 
>> is not going to be so large the Beaglebone can't compile it.
>>
>> Give me an example of what you plan on doing though . . .
>>
>> > Is BBB powerful enough to compile relatively significant source code 
>> amount ?
>> >
>> It depends, see above.
>>
>> > And which IDE do you recommend to work  natively on BBB? The same as 
>> you mentioned above ?
>>
>> I recommend no IDE. I use gcc from the cmd line, and I use several 
>> different text editors to write my code. My setup is a little different 
>> than many. I have an NFS server that shares a directory to the Beaglebone. 
>> On the beaglebone this is where I compile my code, if not in a ramdisk. The 
>> NFS server also run Samba, and exports this same directory out so I can 
>> connect to it from Windows. Then, I use Visual Studio Code, Sublime text 3, 
>> or whatever text editor I like in Windows to write code ( live ) on / for 
>> the Beaglebone. Then it's just a matter of . . .
>>
>> $ gcc somefile.c -o somefile -Wall/* and whatever other options I 
>> want and need */
>> $ chmod +x ./somefile/* File needs to be given executable 
>> permissions */
>> $ ./somefile/* Then the application does its 
>> thing . . .*/
>>
>> On Fri, Jul 1, 2016 at 11:46 AM, ivbsd1  
>> wrote:
>>
>>> William, 
>>>
>>> Thanks for input about using BBB itself.
>>> But I am worried about scalability of this solution. Software tends to 
>>> grow very quickly. 
>>> Is BBB powerful enough to compile relatively significant source code 
>>> amount ?
>>>
>>> And which IDE do you recommend to work  natively on BBB? The same as you 
>>> mentioned above ?
>>>
>>>
>>>
>>> On Friday, July 1, 2016 at 9:39:55 PM UTC+3, William Hermans wrote:

 Additionally, if you're worried about writing too much to flash media ( 
 emmc or sdcard ), just create a 128M ramdisk, and compile your projects in 
 that. You can also setup an NFS share, LInked with a Samba share so you 
 can 
 edit these files easily from within Windows . . . there are a ton of 
 options out there . . .

 On Fri, Jul 1, 2016 at 11:36 AM, William Hermans  
 wrote:

> ivbsd1,
>
> I would like to point out that I use Windows on a daily basis, and 
> have since the 90's. However I will also mention that I consider Windows 
> a 
> really bad choice of a development platform for this hardware.
>
> For really simple applications, or probably even reasonably complex 
> applications, cross compiling form Windows will work fine.
>
> However, you will very soon start noticing problems. How do you get 
> Linux API headers into Windows? How do you compile anything complex on 
> Windows, like Qt, Nodejs, wireshark, or better still a Linux kernel, or 
> kernel module ? The list goes on, and on and . . .
>
> So, I think it would behoove you, or anyone to figure out how to get a 
> Linux system for a development system. Here, I would like to point out 
> that 
> if you have a beaglebone, you already have one. So no need to cross 
> compile, just compile natively on the Beaglebone. This will work fine for 
> 99% of projects out there.
>
> On Fri, Jul 1, 2016 at 11:05 AM, ivbsd1  wrote:
>
>> William, Graham - thanks a lot for valuable inputs.
>>
>> I'm sure that under Linux it will run better. But environment should 
>> comply with some existed IT infrastructure .
>>
>> So, William, I'll try your suggestion.
>>
>>
>> On Friday, July 1, 2016 at 8:55:02 PM UTC+3, William Hermans wrote:
>>>
>>> Additionally. If you *can* live with using Linux. The default 
>>> toolchains supplied with Ubuntu 14.04 work very well too. D.R. Derek 
>>> Molloy 
>>> has youtube videos on setup under Ubuntu, for a suitable toolchain and 
>>> using Eclipse - I think.
>>>
>>> On

[beagleboard] Re: New eMMC with 3.8.13 kernel

2016-07-02 Thread abhilash h 
Hi,

I was able to recompile the kernel (3.8.13-bone70, debian 7)commenting the 
line in mmc.c.
But the image is running fine on the sd card.
When i try to flash to emmc it says panic occured and it hangs. 
What might be the problem. I am stuck for days now.

Regards,
Abhilash

On Tuesday, 14 June 2016 20:36:57 UTC+5:30, Mark wrote:
>
> I have a project that I have been working on for some several years.  It 
> started out on a BeagleBone White, but recently it was moved to the 
> BeagleBone Green so it run off eMMC instead of an SD card.   I have been 
> using embedded Ubuntu 14.04 (trusty) with the 3.8.13-bone79 bb-kernel 
> following the instructions at 
> https://eewiki.net/display/linuxonarm/BeagleBone.
>
> I just received a newer BBG last week and I was unable to flash my image 
> to the eMMC.   Monitoring the debug output, I noticed that the eMMC failed 
> to initialize when the SD card was used so the flashing could not be done. 
>   After some research, it appears that the eMMC hardware has been changed 
> on the Green.   On the BBB Wiki, I also saw that the Black appears to have 
> a similar change in Rev C.  Experimenting with several of the flashing 
> images on http://beagleboard.org/latest-images, the one one I can get 
> working is the Debian 8.4 Jessie version.
>
> Is there a way to get the eMMC working with embedded Ubuntu 14.04 (trusty) 
> with the 3.8.13-bone79 bb-kernel?
>
> Thanks!
>
> Mark
>

-- 
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/167f13c9-1673-46b3-a0e1-51b8d61b42a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.