Re: [beagleboard] Re: debian testing: 2014-11-11

[Jason Lange]

Hi Robert,
withThis worked for me:

/etc/dnsmasq.conf
#disable DNS by setting port to 0
port=0

interface=usb0
dhcp-range=192.168.7.1,192.168.7.1
#one address range


/etc/network/interfaces

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug usb0
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.0
network 192.168.7.0
gateway 192.168.7.1



I'm using your 2014/11/11 jessie image and after I did an apt-get
update/upgrade I lost the ability to connect with ssh. removing udhcpd and
adding the above configuration for dnsmasq restored my ability to connect
via ssh on both interfaces.




On Thu, Nov 13, 2014 at 4:06 PM, Robert Nelson 
wrote:

> > Sure, as long as we can configure dnsmasq to do the work of udhcpd,
> > i'm all for it.. ;)
>
> https://wiki.debian.org/HowTo/dnsmasq
>
> /etc/dnsmasq.conf
>
> dhcp-range=usb0,192.168.7.1,192.168.7.3,12h
>
> look sane?
>
> Regards,
>
> --
> Robert Nelson
> http://www.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel Level Optimization O1

[John Syn]

From:  Przemek Klosowski 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Friday, November 14, 2014 at 7:50 PM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Kernel Level Optimization O1

> The kernel has to be compiled with -O2 or more:
> http://www.tldp.org/LDP/lkmpg/2.4/html/x208.html
Instead of using NFS, I used an SDCard and it booted just fine with O1
optimization. Strange.

Regards,
John
> 
> On Fri, Nov 14, 2014 at 10:16 PM, John Syn  wrote:
>> I¹m using V3.15.10-bone8 kernel with Debian Image 2014-10-08.
>> 
>> I trying to debug a device driver which is built into the kernel to
>> simplify debugging. Building the kernel with O2 optimization makes single
>> stepping difficult so I changed the compiler optimization to O1 in
>> Makefile, but now Debian won¹t boot properly. Anyone have an idea why
>> changing the compiler optimization breaks OS startup? BTW, building the
>> kernel with O2 optimization boots just fine. Here is the bootlog:
>> 
>> Starting kernel ...
>> 
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpu
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 3.15.10-bone8 (john@DX58SO) (gcc version
>> 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04
>>   -
>> Linaro GCC 4.8-2014.04) ) #2 Fri Nov 14 17:32:17 PST 2014
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>> cr=50c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [0.00] Machine model: TI AM335x BeagleBone
>> [0.00] Memory policy: Data cache writeback
>> [0.00] CPU: All CPU(s) started in SVC mode.
>> [0.00] AM335X ES2.0 (sgx neon )
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 129792
>> [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs
>> rw rootfstype=ext4 rootwait fixrtc
>> nfsroot=10.100.116.73:/home/john/targetNFS,vers=3
>> ip=10.100.116.105:10.100.116.73:10.100.f
>> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
>> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
>> bytes)
>> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
>> bytes)
>> [0.00] allocated 1048576 bytes of page_cgroup
>> [0.00] please try 'cgroup_disable=memory' option if you don't want
>> memory cgroups
>> [0.00] Memory: 506528K/523264K available (5866K kernel code, 605K
>> rwdata, 3216K rodata, 330K init, 982K bss, 16736K reserved, 0K highmem)
>> [0.00] Virtual kernel memory layout:
>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>> [0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
>> [0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
>> [0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
>> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> [0.00] modules : 0xbf80 - 0xbfe0   (   6 MB)
>> [0.00]   .text : 0xc0008000 - 0xc08e6a70   (9083 kB)
>> [0.00]   .init : 0xc08e7000 - 0xc0939b80   ( 331 kB)
>> [0.00]   .data : 0xc093a000 - 0xc09d1488   ( 606 kB)
>> [0.00].bss : 0xc09d1488 - 0xc0ac706c   ( 983 kB)
>> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> [0.00] NR_IRQS:16 nr_irqs:16 16
>> [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
>> interrupts
>> [0.00] Total of 128 interrupts on 1 active controller
>> [0.00] OMAP clockevent source: timer2 at 2400 Hz
>> [0.10] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
>> 178956969942ns
>> [0.28] OMAP clocksource: timer1 at 2400 Hz
>> [0.000186] Console: colour dummy device 80x30
>> [0.000209] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
>> [0.089539] pid_max: default: 32768 minimum: 301
>> [0.089607] Security Framework initialized
>> [0.089682] AppArmor: AppArmor disabled by boot time parameter
>> [0.089689] Yama: becoming mindful.
>> [0.089858] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [0.089869] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
>> bytes)
>> [0.090357] Initializing cgroup subsys memory
>> [0.090385] Initializing cgroup subsys devices
>> [0.090395] Initializing cgroup subsys freezer
>> [0.090405] Initializing cgroup subsys net_cls
>> [0.090413] Initializing cgroup subsys blkio
>> [0.090420] Initializing cgroup subsys perf_event
>> [0.090464] CPU: Testing write buffer coherency: ok
>> [0.090753] Setting up static identity map for 0x80574140 - 0x8057418c
>> [0.093825] devtmpfs: initialized
>> [0.095462] VFP support v0.3: implementor 41 architecture 3 part 30
>> variant c rev 3
>> [0.100956] omap_

Re: [beagleboard] UARTs enabled but don't work on Debian!

[Mostafa Jafarzadeh]

Hi Robert,

Many thanks. You saved my day! :-)
I did a loopback on UART2 and UART4 and they're both fine. However UART1 TX 
doesn't work! RX is fine. I had a look at the dtb sources and pins are 
correct. Do you have any idea what's wrong?

Just for the reference, it wasn't really smooth and hassle-free to compile 
DTBs. After installing all dependencies, I had to compile and install 
device-tree-compiler manually according to this tutorial:
http://www.embedded-things.com/bbb/patching-the-device-tree-compiler-for-ubuntu/


On Saturday, November 15, 2014 4:12:22 AM UTC+7, RobertCNelson wrote:
>
> http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb
>
> The pins aren't mixed to the peripheral.
>
> Example enable this
>
>
> https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts#L78
>
> And run...
>
> make ; sudo make install ; sudo reboot
> On Nov 14, 2014 2:46 PM, > wrote:
>
>> I've been playing around with my BBB for about a month now and got 
>> everything up and running. Today I spent the whole day to get UART loopback 
>> to work on Debian. It simply doesn't work! Tried with Qt (cross-compiled 
>> and all samples are working), QSerialPortInfo::availablePorts().count() 
>> returns zero. At first I thought it can be a QtSerialPort issue. So I did a 
>> loop back on UART1 and UART2 (P9.21 connected to P9.26 and P9.22 connected 
>> to P9.24). Then opened "minicom -b 9600 -D /dev/ttyO1" and "minicom -b 9600 
>> -D /dev/ttyO2" in two separate terminals. I expected to see whatever I type 
>> in each one of the terminals on the other one. But that wasn't the case. 
>> Nothing happens! Any idea what's wrong?
>>
>> Here's some info about my setup:
>>
>> *Fresh install of 
>> "BBB-eMMC-flasher-debian-7.7-console-armhf-2014-10-29-2gb.img.xz". Didn't 
>> modify anything. *
>>
>> *"uname -a": *
>> Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Fri Oct 24 20:50:46 UTC 2014 
>> armv7l GNU/Linux
>>
>> *"dmesg | grep ttyO":*
>> [0.00] Kernel command line: console=ttyO0,115200n8 
>> root=UUID=a52b5fd5-953d-458c-94d0-0cf2ff1c7115 ro rootfstype=ext4 rootwait 
>> fixrtc quiet init=/lib/systemd/systemd
>> [2.799292] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88, 
>> base_baud = 300) is a OMAP UART0
>> [2.800424] console [ttyO0] enabled
>> [2.802247] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89, 
>> base_baud = 300) is a OMAP UART1
>> [2.803710] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90, 
>> base_baud = 300) is a OMAP UART2
>> [2.805198] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61, 
>> base_baud = 300) is a OMAP UART4
>> [2.806622] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62, 
>> base_baud = 300) is a OMAP UART5
>>
>> *"ls -al /dev/ttyO*":*
>> crw-rw 1 root tty 249, 0 Oct 29 19:06 /dev/ttyO0
>> crw-rw---T 1 root dialout 249, 1 Nov 14 17:41 /dev/ttyO1
>> crw-rw---T 1 root dialout 249, 2 Nov 14 17:41 /dev/ttyO2
>> crw-rw---T 1 root dialout 249, 4 Jan  1  2000 /dev/ttyO4
>> crw-rw---T 1 root dialout 249, 5 Jan  1  2000 /dev/ttyO5
>>
>>
>> I appreciate anything that might 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...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB Standby when press power button ?

[Minh Phuong Dang]

Hi everyone,

Many thanks for your comments.

Problem solved.

How lucky am I !

I've followed the bellow link, modified the kernel source and it can work 
properly.

https://groups.google.com/forum/#!msg/beagleboard/umJLdbn4pkA/W6u4gQzFmzQJ

Cheer !


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

[beagleboard] Setting up DHCP and TFTP for beaglebone black

[Gadre Nayan]

I want to transfer my kernel image to beaglebone black, and the guide 
mentions that I should have already set up DHCP and tftp on the host 
machine.

I have set up the TFTP using:

>sudo apt-get install tftpd-hpa tftp-hpa

>sudo vim /etc/default/tftpd-hpa 

>TFTP_USERNAME="tftp"

>TFTP_DIRECTORY="your-ftp-root-directory"

>TFTP_ADDRESS="0.0.0.0:69"

>TFTP_OPTIONS="--secure"

>sudo service tftpd restart

Also I need a DHCP server on host so It can assign IP to BBBlack.

SO I followed:

>sudo apt-get install isc-dhcp-server

>sudo /etc/init.d/networking/restart

>nano -w /etc/dhcp/dhcpd.conf

>default-lease-time 600;

>max-lease-time 7200;

>option subnet-mask 255.255.255.0;

>option broadcast-address 192.168.1.255;

>option routers 192.168.1.254;

>option domain-name-servers 192.168.1.1, 192.168.1.2;

>option domain-name "mydomain.example";

>subnet 192.168.1.0 netmask 255.255.255.0 {

>range 192.168.1.10 192.168.1.100;

>range 192.168.1.150 192.168.1.200;

>} `

>ls /etc/default/isc-dhcp-server

>INTERFACES "eth0"



eth0  Link encap:Ethernet  HWaddr 00:23:ae:15:85:ae  
  inet6 addr: fe80::223:aeff:fe15:85ae/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1462 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:279343 (279.3 KB)
  Interrupt:16 



/etc/network/interface



auto lo
iface lo inet loopback

#auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
up service dhcp3-server restart



Yet. The DHCP is not getting setup. 

Please suggest where I may be going wrong

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

Re: [beagleboard] Kernel Level Optimization O1

[John Syn]

From:  Przemek Klosowski 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Friday, November 14, 2014 at 7:50 PM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Kernel Level Optimization O1

> The kernel has to be compiled with -O2 or more:
> http://www.tldp.org/LDP/lkmpg/2.4/html/x208.html
Thanks Przemek , but this article is for Kernel Modules and not for the
kernel. Perhaps something has changed, but I recall years ago that I was
able to compile the kernel with O1, but not with O0.

Regards,
John
> 
> On Fri, Nov 14, 2014 at 10:16 PM, John Syn  wrote:
>> I¹m using V3.15.10-bone8 kernel with Debian Image 2014-10-08.
>> 
>> I trying to debug a device driver which is built into the kernel to
>> simplify debugging. Building the kernel with O2 optimization makes single
>> stepping difficult so I changed the compiler optimization to O1 in
>> Makefile, but now Debian won¹t boot properly. Anyone have an idea why
>> changing the compiler optimization breaks OS startup? BTW, building the
>> kernel with O2 optimization boots just fine. Here is the bootlog:
>> 
>> Starting kernel ...
>> 
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpu
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 3.15.10-bone8 (john@DX58SO) (gcc version
>> 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04
>>   -
>> Linaro GCC 4.8-2014.04) ) #2 Fri Nov 14 17:32:17 PST 2014
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>> cr=50c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [0.00] Machine model: TI AM335x BeagleBone
>> [0.00] Memory policy: Data cache writeback
>> [0.00] CPU: All CPU(s) started in SVC mode.
>> [0.00] AM335X ES2.0 (sgx neon )
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 129792
>> [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs
>> rw rootfstype=ext4 rootwait fixrtc
>> nfsroot=10.100.116.73:/home/john/targetNFS,vers=3
>> ip=10.100.116.105:10.100.116.73:10.100.f
>> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
>> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
>> bytes)
>> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
>> bytes)
>> [0.00] allocated 1048576 bytes of page_cgroup
>> [0.00] please try 'cgroup_disable=memory' option if you don't want
>> memory cgroups
>> [0.00] Memory: 506528K/523264K available (5866K kernel code, 605K
>> rwdata, 3216K rodata, 330K init, 982K bss, 16736K reserved, 0K highmem)
>> [0.00] Virtual kernel memory layout:
>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>> [0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
>> [0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
>> [0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
>> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> [0.00] modules : 0xbf80 - 0xbfe0   (   6 MB)
>> [0.00]   .text : 0xc0008000 - 0xc08e6a70   (9083 kB)
>> [0.00]   .init : 0xc08e7000 - 0xc0939b80   ( 331 kB)
>> [0.00]   .data : 0xc093a000 - 0xc09d1488   ( 606 kB)
>> [0.00].bss : 0xc09d1488 - 0xc0ac706c   ( 983 kB)
>> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> [0.00] NR_IRQS:16 nr_irqs:16 16
>> [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
>> interrupts
>> [0.00] Total of 128 interrupts on 1 active controller
>> [0.00] OMAP clockevent source: timer2 at 2400 Hz
>> [0.10] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
>> 178956969942ns
>> [0.28] OMAP clocksource: timer1 at 2400 Hz
>> [0.000186] Console: colour dummy device 80x30
>> [0.000209] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
>> [0.089539] pid_max: default: 32768 minimum: 301
>> [0.089607] Security Framework initialized
>> [0.089682] AppArmor: AppArmor disabled by boot time parameter
>> [0.089689] Yama: becoming mindful.
>> [0.089858] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [0.089869] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
>> bytes)
>> [0.090357] Initializing cgroup subsys memory
>> [0.090385] Initializing cgroup subsys devices
>> [0.090395] Initializing cgroup subsys freezer
>> [0.090405] Initializing cgroup subsys net_cls
>> [0.090413] Initializing cgroup subsys blkio
>> [0.090420] Initializing cgroup subsys perf_event
>> [0.090464] CPU: Testing write buffer coherency: ok
>> [0.090753] Setting up static identity map for 0x80574140 - 0x8057418c
>> [0.093825] devtmpfs: initialized
>> [0.09

Re: [beagleboard] Kernel Level Optimization O1

[Przemek Klosowski]

The kernel has to be compiled with -O2 or more:
http://www.tldp.org/LDP/lkmpg/2.4/html/x208.html

On Fri, Nov 14, 2014 at 10:16 PM, John Syn  wrote:

> I¹m using V3.15.10-bone8 kernel with Debian Image 2014-10-08.
>
> I trying to debug a device driver which is built into the kernel to
> simplify debugging. Building the kernel with O2 optimization makes single
> stepping difficult so I changed the compiler optimization to O1 in
> Makefile, but now Debian won¹t boot properly. Anyone have an idea why
> changing the compiler optimization breaks OS startup? BTW, building the
> kernel with O2 optimization boots just fine. Here is the bootlog:
>
> Starting kernel ...
>
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 3.15.10-bone8 (john@DX58SO) (gcc version
> 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 -
> Linaro GCC 4.8-2014.04) ) #2 Fri Nov 14 17:32:17 PST 2014
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
> cr=50c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [0.00] Machine model: TI AM335x BeagleBone
> [0.00] Memory policy: Data cache writeback
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES2.0 (sgx neon )
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 129792
> [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs
> rw rootfstype=ext4 rootwait fixrtc
> nfsroot=10.100.116.73:/home/john/targetNFS,vers=3
> ip=10.100.116.105:10.100.116.73:10.100.f
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
> bytes)
> [0.00] allocated 1048576 bytes of page_cgroup
> [0.00] please try 'cgroup_disable=memory' option if you don't want
> memory cgroups
> [0.00] Memory: 506528K/523264K available (5866K kernel code, 605K
> rwdata, 3216K rodata, 330K init, 982K bss, 16736K reserved, 0K highmem)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
> [0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
> [0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
> [0.00] modules : 0xbf80 - 0xbfe0   (   6 MB)
> [0.00]   .text : 0xc0008000 - 0xc08e6a70   (9083 kB)
> [0.00]   .init : 0xc08e7000 - 0xc0939b80   ( 331 kB)
> [0.00]   .data : 0xc093a000 - 0xc09d1488   ( 606 kB)
> [0.00].bss : 0xc09d1488 - 0xc0ac706c   ( 983 kB)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
> interrupts
> [0.00] Total of 128 interrupts on 1 active controller
> [0.00] OMAP clockevent source: timer2 at 2400 Hz
> [0.10] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
> 178956969942ns
> [0.28] OMAP clocksource: timer1 at 2400 Hz
> [0.000186] Console: colour dummy device 80x30
> [0.000209] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
> [0.089539] pid_max: default: 32768 minimum: 301
> [0.089607] Security Framework initialized
> [0.089682] AppArmor: AppArmor disabled by boot time parameter
> [0.089689] Yama: becoming mindful.
> [0.089858] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [0.089869] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
> bytes)
> [0.090357] Initializing cgroup subsys memory
> [0.090385] Initializing cgroup subsys devices
> [0.090395] Initializing cgroup subsys freezer
> [0.090405] Initializing cgroup subsys net_cls
> [0.090413] Initializing cgroup subsys blkio
> [0.090420] Initializing cgroup subsys perf_event
> [0.090464] CPU: Testing write buffer coherency: ok
> [0.090753] Setting up static identity map for 0x80574140 - 0x8057418c
> [0.093825] devtmpfs: initialized
> [0.095462] VFP support v0.3: implementor 41 architecture 3 part 30
> variant c rev 3
> [0.100956] omap_hwmod: tptc0 using broken dt data from edma
> [0.101025] omap_hwmod: tptc1 using broken dt data from edma
> [0.101084] omap_hwmod: tptc2 using broken dt data from edma
> [0.157535] xor: measuring software checksum speed
> [0.249512]arm4regs  :  1247.200 MB/sec
> [0.349512]8regs :   867.600 MB/sec
> [0.449510]32regs:   890.800 MB/sec
> [0.549509]neon  :  1697

[beagleboard] Kernel Level Optimization O1

[John Syn]

I¹m using V3.15.10-bone8 kernel with Debian Image 2014-10-08.

I trying to debug a device driver which is built into the kernel to
simplify debugging. Building the kernel with O2 optimization makes single
stepping difficult so I changed the compiler optimization to O1 in
Makefile, but now Debian won¹t boot properly. Anyone have an idea why
changing the compiler optimization breaks OS startup? BTW, building the
kernel with O2 optimization boots just fine. Here is the bootlog:

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.15.10-bone8 (john@DX58SO) (gcc version
4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 -
Linaro GCC 4.8-2014.04) ) #2 Fri Nov 14 17:32:17 PST 2014
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
cr=50c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: TI AM335x BeagleBone
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES2.0 (sgx neon )
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 129792
[0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs
rw rootfstype=ext4 rootwait fixrtc
nfsroot=10.100.116.73:/home/john/targetNFS,vers=3
ip=10.100.116.105:10.100.116.73:10.100.f
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[0.00] allocated 1048576 bytes of page_cgroup
[0.00] please try 'cgroup_disable=memory' option if you don't want
memory cgroups
[0.00] Memory: 506528K/523264K available (5866K kernel code, 605K
rwdata, 3216K rodata, 330K init, 982K bss, 16736K reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
[0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf80 - 0xbfe0   (   6 MB)
[0.00]   .text : 0xc0008000 - 0xc08e6a70   (9083 kB)
[0.00]   .init : 0xc08e7000 - 0xc0939b80   ( 331 kB)
[0.00]   .data : 0xc093a000 - 0xc09d1488   ( 606 kB)
[0.00].bss : 0xc09d1488 - 0xc0ac706c   ( 983 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent source: timer2 at 2400 Hz
[0.10] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
178956969942ns
[0.28] OMAP clocksource: timer1 at 2400 Hz
[0.000186] Console: colour dummy device 80x30
[0.000209] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
[0.089539] pid_max: default: 32768 minimum: 301
[0.089607] Security Framework initialized
[0.089682] AppArmor: AppArmor disabled by boot time parameter
[0.089689] Yama: becoming mindful.
[0.089858] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.089869] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
bytes)
[0.090357] Initializing cgroup subsys memory
[0.090385] Initializing cgroup subsys devices
[0.090395] Initializing cgroup subsys freezer
[0.090405] Initializing cgroup subsys net_cls
[0.090413] Initializing cgroup subsys blkio
[0.090420] Initializing cgroup subsys perf_event
[0.090464] CPU: Testing write buffer coherency: ok
[0.090753] Setting up static identity map for 0x80574140 - 0x8057418c
[0.093825] devtmpfs: initialized
[0.095462] VFP support v0.3: implementor 41 architecture 3 part 30
variant c rev 3
[0.100956] omap_hwmod: tptc0 using broken dt data from edma
[0.101025] omap_hwmod: tptc1 using broken dt data from edma
[0.101084] omap_hwmod: tptc2 using broken dt data from edma
[0.157535] xor: measuring software checksum speed
[0.249512]arm4regs  :  1247.200 MB/sec
[0.349512]8regs :   867.600 MB/sec
[0.449510]32regs:   890.800 MB/sec
[0.549509]neon  :  1697.200 MB/sec
[0.549517] xor: using function: neon (1697.200 MB/sec)
[0.549533] pinctrl core: initialized pinctrl subsystem
[0.549882] regulator-dummy: no parameters
[0.557028] NET: Registered protocol family 16
[0.557603] DMA: preallocated 256 KiB pool for atomic coherent
allocations
[0.558242] cpuidle:

Re: [beagleboard] installing a permanent cape

[William Hermans]

reboot=soft for a kernel parameter, *maybe*.

On Fri, Nov 14, 2014 at 3:57 PM,  wrote:

> Hi,
> I have beagle bone with 4d system lcd cape-70t.
> Now I have debian and every thing works great.
> but since this would be my permanent configuration I do not want beagle
> bone to read the cape EEPROM on every boot.
> How can I tell the Kernel that this is the cape that is installed and do
> not read cape eeproms.
>
> Regards,
> Ramin
>
>  --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone-universal-io and analog input

[Robert Nelson]

On Nov 14, 2014 5:35 PM, "Tux Leonard"  wrote:
>
> Thanks.
> Now I got the capemgr but no permission to write to the slots
>
> sudo echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.9/slots
>
> -bash: /sys/devices/bone_capemgr.9/slots: Permission denied

Well yeah...

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Privileged_echo

>
>
>
> 2014-11-14 22:32 GMT+01:00 Robert Nelson :
>>
>>
>> On Nov 14, 2014 3:24 PM, "Tux Leonard"  wrote:
>> >
>> > This libpruio looks good. The problem is that I can't get it running.
>> > I think this is related tu the kernel (3.14.x or 3.17.x) version I am
using. There is no capemgr any more.
>> > Could you suggest me a linux image or kernel version I should use?
>>
>> sudo apt-get update
>> sudo apt-get install linux-image-3.8.13-bone67
>> sudo reboot
>>
>>
>> >
>> > 2014-11-08 19:12 GMT+01:00 TJF :
>> >>
>> >>
>> >> Hello Roy,
>> >>
>> >> there's an alternative way to fetch ADC data on the BBB. The library
libpruio provides several functions to fetch analog input, much faster and
more flexible than sysfs. It also allows to configure the ADC subsystem
steps. And furthermore it supports digital IO (GPIO, PWM and CAP).
>> >>
>> >> --
>> >> 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.
>> >> 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.
>> > 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.
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone-universal-io and analog input

[William Hermans]

google "privileged commands" for linux. You need root, or us an additional
"switch" with sudo. sudo -sh  I believe. Also, you can fix this in
the sudoers file by having that user set to use roots user:passwd

On Fri, Nov 14, 2014 at 4:35 PM, Tux Leonard  wrote:

> Thanks.
> Now I got the capemgr but no permission to write to the slots
>
> sudo echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.9/slots
>
> -bash: /sys/devices/bone_capemgr.9/slots: Permission denied
>
>
> 2014-11-14 22:32 GMT+01:00 Robert Nelson :
>
>>
>> On Nov 14, 2014 3:24 PM, "Tux Leonard"  wrote:
>> >
>> > This libpruio looks good. The problem is that I can't get it running.
>> > I think this is related tu the kernel (3.14.x or 3.17.x) version I am
>> using. There is no capemgr any more.
>> > Could you suggest me a linux image or kernel version I should use?
>>
>> sudo apt-get update
>> sudo apt-get install linux-image-3.8.13-bone67
>> sudo reboot
>>
>>
>> >
>> > 2014-11-08 19:12 GMT+01:00 TJF :
>> >>
>> >>
>> >> Hello Roy,
>> >>
>> >> there's an alternative way to fetch ADC data on the BBB. The library
>> libpruio provides several functions to fetch analog input, much faster and
>> more flexible than sysfs. It also allows to configure the ADC subsystem
>> steps. And furthermore it supports digital IO (GPIO, PWM and CAP).
>> >>
>> >> --
>> >> 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.
>> >> 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.
>> > 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.
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone-universal-io and analog input

[Tux Leonard]

Thanks.
Now I got the capemgr but no permission to write to the slots

sudo echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.9/slots

-bash: /sys/devices/bone_capemgr.9/slots: Permission denied


2014-11-14 22:32 GMT+01:00 Robert Nelson :

>
> On Nov 14, 2014 3:24 PM, "Tux Leonard"  wrote:
> >
> > This libpruio looks good. The problem is that I can't get it running.
> > I think this is related tu the kernel (3.14.x or 3.17.x) version I am
> using. There is no capemgr any more.
> > Could you suggest me a linux image or kernel version I should use?
>
> sudo apt-get update
> sudo apt-get install linux-image-3.8.13-bone67
> sudo reboot
>
>
> >
> > 2014-11-08 19:12 GMT+01:00 TJF :
> >>
> >>
> >> Hello Roy,
> >>
> >> there's an alternative way to fetch ADC data on the BBB. The library
> libpruio provides several functions to fetch analog input, much faster and
> more flexible than sysfs. It also allows to configure the ADC subsystem
> steps. And furthermore it supports digital IO (GPIO, PWM and CAP).
> >>
> >> --
> >> 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.
> >> 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.
> > 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] installing a permanent cape

[rabelivan]

Hi,
I have beagle bone with 4d system lcd cape-70t. 
Now I have debian and every thing works great.
but since this would be my permanent configuration I do not want beagle 
bone to read the cape EEPROM on every boot.
How can I tell the Kernel that this is the cape that is installed and do 
not read cape eeproms.

Regards,
Ramin

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

Re: [beagleboard] Re: Labolatory power supply fails to power up BeagleBone Black

[Graham Haddock]

Gerald:

Well, in the case of the B&K 1550, set to 5.0 Volts, and any reasonable
current limit, if the power supply output is turned on,
and the power supply cap in the Beaglebone Black is fully discharged,
then the BBB never starts. Just one blink of the power LED then nothing.
On the oscilloscope, voltage rises from zero to 6 Volts in one ms, then
decays back to 5.0 Volts over 100 ms. or so. Probably trips the overvoltage
detect in the BBB power chip, which must be latching.

If you cycle the output off, wait about three seconds, then on, and the caps
in the BBB have dropped enough to reset the BBB power chip, but not
decayed all the way back to zero, then the over shoot voltage is less when
you turn it back on, and the BBB will generally start on this second try.

P.O.S. power supply.

--- Graham

==



On Fri, Nov 14, 2014 at 1:39 PM, Gerald Coley 
wrote:

> I have seen it on one board. Funny thing is it does not always do it.
>
> Gerald
>
>
> On Fri, Nov 14, 2014 at 11:45 AM, John Syn  wrote:
>
>>
>> From: Graham 
>> Reply-To: "beagleboard@googlegroups.com" 
>> Date: Friday, November 14, 2014 at 8:03 AM
>> To: "beagleboard@googlegroups.com" 
>> Subject: [beagleboard] Re: Labolatory power supply fails to power up
>> BeagleBone Black
>>
>> I have a similar problem, using a "B&K Precision 1550" Lab Bench Power
>> Supply.
>> When you turn on the Output of the supply, the BBB Power Light blinks
>> once and
>> the BeagleBone Black does not boot.
>>
>> If you put an oscilloscope on the output of the supply and watch it turn
>> on, then
>> the power supply overshoots up to 6 Volts, before returning to the 5 Volt
>> setting.
>>
>> That is just crazy. I have never seen a bench power supply do this.
>> Perhaps you should contact B&K, because there must be something wrong with
>> the voltage regulation on your power supply.
>>
>> Regards,
>> John
>>
>>
>>
>> It turns out that the Power Management IC used in the Beaglebone Black
>> will
>> do an over-voltage shutdown at 6 Volts for protection. So, that is why it
>> does
>> one-blink then shuts-off.
>>
>> So, not only do you need a certain rise time, which the B&K power supply
>> meets, but  you can not have any large overshoot.  No good power supply
>> should have this much overshoot, but the B&K does, so it has problems
>> running a BBB.
>>
>> --- Graham
>>
>> ==
>>
>> On Friday, November 14, 2014 4:03:37 AM UTC-6, bremenpl wrote:
>>>
>>> Hello there,
>>> I have a very strange problem with powering up BeagleBone Black (rev
>>> C) When i try to power it up from some cheap AC adapter it works fine,
>>> but when I connect to to my labolatory power supply the power LED on board
>>> is lid for a second and then doesnt power up the MCU and turns off intead.
>>> I have connected both supplys to osciloscope and they are both stable, the
>>> laboratory one even more. Why is the power controller on the BeagleBone
>>> Black refusing to power up the MCU when powered from lab supply? I have no
>>> idea what is this about. I would aprichiate 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.
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
> http://circuitco.com/support/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone-universal-io and analog input

[Robert Nelson]

On Nov 14, 2014 3:24 PM, "Tux Leonard"  wrote:
>
> This libpruio looks good. The problem is that I can't get it running.
> I think this is related tu the kernel (3.14.x or 3.17.x) version I am
using. There is no capemgr any more.
> Could you suggest me a linux image or kernel version I should use?

sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone67
sudo reboot


>
> 2014-11-08 19:12 GMT+01:00 TJF :
>>
>>
>> Hello Roy,
>>
>> there's an alternative way to fetch ADC data on the BBB. The library
libpruio provides several functions to fetch analog input, much faster and
more flexible than sysfs. It also allows to configure the ADC subsystem
steps. And furthermore it supports digital IO (GPIO, PWM and CAP).
>>
>> --
>> 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.
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone-universal-io and analog input

[Tux Leonard]

This libpruio looks good. The problem is that I can't get it running.
I think this is related tu the kernel (3.14.x or 3.17.x) version I am
using. There is no capemgr any more.
Could you suggest me a linux image or kernel version I should use?

2014-11-08 19:12 GMT+01:00 TJF :

>
> Hello Roy,
>
> there's an alternative way to fetch ADC data on the BBB. The library
> libpruio  provides several
> functions to fetch analog input, much faster and more flexible than sysfs.
> It also allows to configure the ADC subsystem steps. And furthermore it
> supports digital IO (GPIO, PWM and CAP).
>
>  --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO pins and Device Trees with 3.14 kernel

[Robert Nelson]

On Nov 14, 2014 3:11 PM, "Peter Gregory"  wrote:
>
> Yes, that,was a typo.
>
> #sudo echo 2 > /sys/class/pwm/export
>
> I thought that would export EHRPWM2 so I could configure it.
>
> I have a LCD cape 4DSCape-43T
> I'm loading am335x-boneblack-4dcape-43t.dtb
>
> Do I need to load a different dtb to enable pwm?

No.. Someone actually had to figure out how to enable the pwm via the DTS
in v3.14.x...

Hint I haven't much time on it nor figured it out.. Hence its not enabled
by default.

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

Re: [beagleboard] UARTs enabled but don't work on Debian!

[Robert Nelson]

http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

The pins aren't mixed to the peripheral.

Example enable this

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts#L78

And run...

make ; sudo make install ; sudo reboot
On Nov 14, 2014 2:46 PM,  wrote:

> I've been playing around with my BBB for about a month now and got
> everything up and running. Today I spent the whole day to get UART loopback
> to work on Debian. It simply doesn't work! Tried with Qt (cross-compiled
> and all samples are working), QSerialPortInfo::availablePorts().count()
> returns zero. At first I thought it can be a QtSerialPort issue. So I did a
> loop back on UART1 and UART2 (P9.21 connected to P9.26 and P9.22 connected
> to P9.24). Then opened "minicom -b 9600 -D /dev/ttyO1" and "minicom -b 9600
> -D /dev/ttyO2" in two separate terminals. I expected to see whatever I type
> in each one of the terminals on the other one. But that wasn't the case.
> Nothing happens! Any idea what's wrong?
>
> Here's some info about my setup:
>
> *Fresh install of
> "BBB-eMMC-flasher-debian-7.7-console-armhf-2014-10-29-2gb.img.xz". Didn't
> modify anything. *
>
> *"uname -a": *
> Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Fri Oct 24 20:50:46 UTC 2014
> armv7l GNU/Linux
>
> *"dmesg | grep ttyO":*
> [0.00] Kernel command line: console=ttyO0,115200n8
> root=UUID=a52b5fd5-953d-458c-94d0-0cf2ff1c7115 ro rootfstype=ext4 rootwait
> fixrtc quiet init=/lib/systemd/systemd
> [2.799292] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88,
> base_baud = 300) is a OMAP UART0
> [2.800424] console [ttyO0] enabled
> [2.802247] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89,
> base_baud = 300) is a OMAP UART1
> [2.803710] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90,
> base_baud = 300) is a OMAP UART2
> [2.805198] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61,
> base_baud = 300) is a OMAP UART4
> [2.806622] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62,
> base_baud = 300) is a OMAP UART5
>
> *"ls -al /dev/ttyO*":*
> crw-rw 1 root tty 249, 0 Oct 29 19:06 /dev/ttyO0
> crw-rw---T 1 root dialout 249, 1 Nov 14 17:41 /dev/ttyO1
> crw-rw---T 1 root dialout 249, 2 Nov 14 17:41 /dev/ttyO2
> crw-rw---T 1 root dialout 249, 4 Jan  1  2000 /dev/ttyO4
> crw-rw---T 1 root dialout 249, 5 Jan  1  2000 /dev/ttyO5
>
>
> I appreciate anything that might 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO pins and Device Trees with 3.14 kernel

[Peter Gregory]

Yes, that,was a typo.

#sudo echo 2 > /sys/class/pwm/export

I thought that would export EHRPWM2 so I could configure it.

I have a LCD cape 4DSCape-43T
I'm loading am335x-boneblack-4dcape-43t.dtb

Do I need to load a different dtb to enable pwm?

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

[beagleboard] UARTs enabled but don't work on Debian!

[m . jafarzadeh]

I've been playing around with my BBB for about a month now and got 
everything up and running. Today I spent the whole day to get UART loopback 
to work on Debian. It simply doesn't work! Tried with Qt (cross-compiled 
and all samples are working), QSerialPortInfo::availablePorts().count() 
returns zero. At first I thought it can be a QtSerialPort issue. So I did a 
loop back on UART1 and UART2 (P9.21 connected to P9.26 and P9.22 connected 
to P9.24). Then opened "minicom -b 9600 -D /dev/ttyO1" and "minicom -b 9600 
-D /dev/ttyO2" in two separate terminals. I expected to see whatever I type 
in each one of the terminals on the other one. But that wasn't the case. 
Nothing happens! Any idea what's wrong?

Here's some info about my setup:

*Fresh install of 
"BBB-eMMC-flasher-debian-7.7-console-armhf-2014-10-29-2gb.img.xz". Didn't 
modify anything. *

*"uname -a": *
Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Fri Oct 24 20:50:46 UTC 2014 armv7l 
GNU/Linux

*"dmesg | grep ttyO":*
[0.00] Kernel command line: console=ttyO0,115200n8 
root=UUID=a52b5fd5-953d-458c-94d0-0cf2ff1c7115 ro rootfstype=ext4 rootwait 
fixrtc quiet init=/lib/systemd/systemd
[2.799292] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88, 
base_baud = 300) is a OMAP UART0
[2.800424] console [ttyO0] enabled
[2.802247] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89, 
base_baud = 300) is a OMAP UART1
[2.803710] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90, 
base_baud = 300) is a OMAP UART2
[2.805198] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61, 
base_baud = 300) is a OMAP UART4
[2.806622] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62, 
base_baud = 300) is a OMAP UART5

*"ls -al /dev/ttyO*":*
crw-rw 1 root tty 249, 0 Oct 29 19:06 /dev/ttyO0
crw-rw---T 1 root dialout 249, 1 Nov 14 17:41 /dev/ttyO1
crw-rw---T 1 root dialout 249, 2 Nov 14 17:41 /dev/ttyO2
crw-rw---T 1 root dialout 249, 4 Jan  1  2000 /dev/ttyO4
crw-rw---T 1 root dialout 249, 5 Jan  1  2000 /dev/ttyO5


I appreciate anything that might 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

I have seen it on one board. Funny thing is it does not always do it.

Gerald


On Fri, Nov 14, 2014 at 11:45 AM, John Syn  wrote:

>
> From: Graham 
> Reply-To: "beagleboard@googlegroups.com" 
> Date: Friday, November 14, 2014 at 8:03 AM
> To: "beagleboard@googlegroups.com" 
> Subject: [beagleboard] Re: Labolatory power supply fails to power up
> BeagleBone Black
>
> I have a similar problem, using a "B&K Precision 1550" Lab Bench Power
> Supply.
> When you turn on the Output of the supply, the BBB Power Light blinks once
> and
> the BeagleBone Black does not boot.
>
> If you put an oscilloscope on the output of the supply and watch it turn
> on, then
> the power supply overshoots up to 6 Volts, before returning to the 5 Volt
> setting.
>
> That is just crazy. I have never seen a bench power supply do this.
> Perhaps you should contact B&K, because there must be something wrong with
> the voltage regulation on your power supply.
>
> Regards,
> John
>
>
>
> It turns out that the Power Management IC used in the Beaglebone Black will
> do an over-voltage shutdown at 6 Volts for protection. So, that is why it
> does
> one-blink then shuts-off.
>
> So, not only do you need a certain rise time, which the B&K power supply
> meets, but  you can not have any large overshoot.  No good power supply
> should have this much overshoot, but the B&K does, so it has problems
> running a BBB.
>
> --- Graham
>
> ==
>
> On Friday, November 14, 2014 4:03:37 AM UTC-6, bremenpl wrote:
>>
>> Hello there,
>> I have a very strange problem with powering up BeagleBone Black (rev
>> C) When i try to power it up from some cheap AC adapter it works fine,
>> but when I connect to to my labolatory power supply the power LED on board
>> is lid for a second and then doesnt power up the MCU and turns off intead.
>> I have connected both supplys to osciloscope and they are both stable, the
>> laboratory one even more. Why is the power controller on the BeagleBone
>> Black refusing to power up the MCU when powered from lab supply? I have no
>> idea what is this about. I would aprichiate 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.
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

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

Re: [beagleboard] GPIO pins and Device Trees with 3.14 kernel

[Chad Baker]

> On Nov 13, 2014, at 9:33 PM, Peter Gregory  wrote:
> 
> So, I can get config-pin to install by getting the universal-io from git
> 
> #apt-get install gcc g++ make device-tree-compiler
> #git clone https://github.com/cdsteinkuehler/beaglebone-universal-io
> #cd beaglebone-universal-io/
> #make
> #sudo make install
> 
> after that, I can change the mode of my pin 
> 
> PIN  8 - P8-19 gpio0[22] 22 0x820 EHRPWM2A
> 
> to PWM with:
> 
> #config-pin p8.19 pwm
> 
> it changes the configuration, I can verify it by checking with
> 
> #config-pin -q p8.19
> 
> however, I can't export the pin using:
> 
> sudo cat 2 > /sys/class/pwm/export

???
sudo echo 2 >  /sys/class/pwm/export
maybe?
"cat 2” would try to concatenate (or print) a file named “2” to stdout and then 
redirect it to a file named /sys/class/pwm/export

> 
> it always comes back with permission denied
> 
> also, the /sys/class/pwm directory is empty, there should be something in 
> there, right?
> 
> Any ideas what I need to do to get pwm working?
> 
> 
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Leaking memory in kernel 3.8.13bone65 ?

[William Hermans]

ever == over

On Fri, Nov 14, 2014 at 12:09 PM, William Hermans  wrote:

> Yes . . . right now I have 25MB used, but if i use apt-get update &&
> apt-get upgrade to update Debian. The system will show ever 100MB used by
> the system, after done, and nothing else running.
>
> On Fri, Nov 14, 2014 at 6:48 AM, Micka  wrote:
>
>> I got my answer :
>>
>>
>> "A running Linux system will quickly end up allocating all "free" memory
>> to disk cache. This memory is still free because it can be reclaimed from
>> cache and given to processes without any delay"
>>
>> Micka,
>>
>> Le Fri Nov 14 2014 at 14:04:34, Micka  a écrit :
>>
>> HI,
>>>
>>>
>>> I'm working on a beaglebone black kernel 3.8.13bone65 .
>>>
>>>
>>> My problem is that I don't have any program running, but the memory is
>>> almost full  :
>>>
>>> root@beaglebone:~# uname -a
>>> Linux beaglebone 3.8.13-bone65 #3 SMP Thu Sep 18 09:39:21 CEST 2014
>>> armv7l GNU/Linux
>>>
>>>
>>> root@beaglebone:~# free -m
>>>  total   used   free sharedbuffers cached
>>> Mem:   496410 85  0 78184
>>> -/+ buffers/cache:146349
>>> Swap:0  0  0
>>>
>>>
>>> root@beaglebone:~# ps aux --sort -rss
>>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
>>> root  1094  0.2  1.4  14760  7576 ?SFeb24   7:48
>>> /usr/bin/python -O /usr/share/wicd/daemon/monitor.py
>>> root  1086  0.5  1.3  23880  6924 ?SFeb24  17:35
>>> /usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
>>> root   958  0.0  1.0  12484  5360 tty2 Ss+  Feb24   0:00 X
>>> root   680  0.0  0.6  25416  3300 ?Ssl  Feb24   0:00
>>> /usr/sbin/console-kit-daemon --no-daemon
>>> root   681  0.0  0.6  24548  3152 ?Ssl  Feb24   0:00
>>> /usr/lib/upower/upowerd
>>> root   868  0.0  0.5  21936  2744 ?Ssl  Feb24   0:00
>>> /usr/lib/policykit-1/polkitd --no-debug
>>> root 1  0.0  0.5   4496  2656 ?Ss   Feb24   0:01
>>> /lib/systemd/systemd
>>> root  4915  0.0  0.4   7860  2360 ?Ss   22:46   0:00 sshd:
>>> root@notty
>>> root  5478  0.0  0.4   7860  2360 ?Ss   23:32   0:00 sshd:
>>> root@notty
>>> root  5502  0.3  0.4   7720  2332 ?Ss   23:34   0:01 sshd:
>>> root@pts/0
>>> root   676  0.0  0.3   4600  1564 ?Ss   Feb24   0:00
>>> /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant
>>> root   203  0.0  0.3   4404  1532 ?Ss   Feb24   0:10
>>> /lib/systemd/systemd-journald
>>> root   682  0.0  0.3  28392  1528 ?Ssl  Feb24   0:03
>>> /usr/sbin/rsyslogd -n -c5
>>> root  5505  0.0  0.2   2640  1520 pts/0Ss   23:34   0:00 -bash
>>> avahi  667  0.0  0.2   2760  1432 ?Ss   Feb24   0:00
>>> avahi-daemon: running [beaglebone.local]
>>> 101673  0.2  0.2   2716  1424 ?Ss   Feb24   7:15
>>> /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --sys
>>> root   225  0.0  0.2   2544  1416 ?Ss   Feb24   0:00
>>> /sbin/udevd
>>> root   677  0.0  0.2   2916  1264 ?Ss   Feb24   0:00
>>> /lib/systemd/systemd-logind
>>> root   978  0.0  0.2   2540  1084 ?SFeb24   0:00
>>> /sbin/udevd
>>> root   979  0.0  0.2   2540  1024 ?SFeb24   0:00
>>> /sbin/udevd
>>> root   884  0.0  0.1   5160   968 ?Ss   Feb24   0:00
>>> /usr/sbin/sshd
>>> root  5614  0.0  0.1   2484   916 pts/0R+   23:41   0:00 ps aux
>>> --sort -rss
>>> root  4918  0.0  0.1   1772   796 ?Ss   22:46   0:00
>>> /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
>>> root  5481  0.0  0.1   1772   796 ?Ss   23:32   0:00
>>> /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
>>> root   701  0.0  0.1   3344   716 tty1 Ss+  Feb24   0:00
>>> /sbin/agetty tty1 38400
>>> root   702  0.0  0.1   3164   712 ttyO0Ss+  Feb24   0:00
>>> /sbin/agetty -s ttyO0 115200 38400 9600
>>> root   890  0.0  0.1   3356   704 ?Ss   Feb24   0:01
>>> /usr/sbin/cron
>>> root   674  0.0  0.1   1332   684 ?Ss   Feb24   0:00
>>> /usr/sbin/acpid
>>> root  1010  0.0  0.1   1780   544 ?Ss   Feb24   0:00
>>> /usr/sbin/udhcpd -S /etc/udhcpd.conf
>>> avahi  717  0.0  0.0   2760   500 ?SFeb24   0:00
>>> avahi-daemon: chroot helper
>>>
>>>
>>> Do you know how can i find out who is using that much of memory ? Do you
>>> think that it can be the kernel ? the log ?
>>>
>>> Micka,
>>>
>>>
>>>
>>>  --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
---

Re: [beagleboard] Re: Leaking memory in kernel 3.8.13bone65 ?

[William Hermans]

Yes . . . right now I have 25MB used, but if i use apt-get update &&
apt-get upgrade to update Debian. The system will show ever 100MB used by
the system, after done, and nothing else running.

On Fri, Nov 14, 2014 at 6:48 AM, Micka  wrote:

> I got my answer :
>
>
> "A running Linux system will quickly end up allocating all "free" memory
> to disk cache. This memory is still free because it can be reclaimed from
> cache and given to processes without any delay"
>
> Micka,
>
> Le Fri Nov 14 2014 at 14:04:34, Micka  a écrit :
>
> HI,
>>
>>
>> I'm working on a beaglebone black kernel 3.8.13bone65 .
>>
>>
>> My problem is that I don't have any program running, but the memory is
>> almost full  :
>>
>> root@beaglebone:~# uname -a
>> Linux beaglebone 3.8.13-bone65 #3 SMP Thu Sep 18 09:39:21 CEST 2014
>> armv7l GNU/Linux
>>
>>
>> root@beaglebone:~# free -m
>>  total   used   free sharedbuffers cached
>> Mem:   496410 85  0 78184
>> -/+ buffers/cache:146349
>> Swap:0  0  0
>>
>>
>> root@beaglebone:~# ps aux --sort -rss
>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
>> root  1094  0.2  1.4  14760  7576 ?SFeb24   7:48
>> /usr/bin/python -O /usr/share/wicd/daemon/monitor.py
>> root  1086  0.5  1.3  23880  6924 ?SFeb24  17:35
>> /usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
>> root   958  0.0  1.0  12484  5360 tty2 Ss+  Feb24   0:00 X
>> root   680  0.0  0.6  25416  3300 ?Ssl  Feb24   0:00
>> /usr/sbin/console-kit-daemon --no-daemon
>> root   681  0.0  0.6  24548  3152 ?Ssl  Feb24   0:00
>> /usr/lib/upower/upowerd
>> root   868  0.0  0.5  21936  2744 ?Ssl  Feb24   0:00
>> /usr/lib/policykit-1/polkitd --no-debug
>> root 1  0.0  0.5   4496  2656 ?Ss   Feb24   0:01
>> /lib/systemd/systemd
>> root  4915  0.0  0.4   7860  2360 ?Ss   22:46   0:00 sshd:
>> root@notty
>> root  5478  0.0  0.4   7860  2360 ?Ss   23:32   0:00 sshd:
>> root@notty
>> root  5502  0.3  0.4   7720  2332 ?Ss   23:34   0:01 sshd:
>> root@pts/0
>> root   676  0.0  0.3   4600  1564 ?Ss   Feb24   0:00
>> /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant
>> root   203  0.0  0.3   4404  1532 ?Ss   Feb24   0:10
>> /lib/systemd/systemd-journald
>> root   682  0.0  0.3  28392  1528 ?Ssl  Feb24   0:03
>> /usr/sbin/rsyslogd -n -c5
>> root  5505  0.0  0.2   2640  1520 pts/0Ss   23:34   0:00 -bash
>> avahi  667  0.0  0.2   2760  1432 ?Ss   Feb24   0:00
>> avahi-daemon: running [beaglebone.local]
>> 101673  0.2  0.2   2716  1424 ?Ss   Feb24   7:15
>> /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --sys
>> root   225  0.0  0.2   2544  1416 ?Ss   Feb24   0:00
>> /sbin/udevd
>> root   677  0.0  0.2   2916  1264 ?Ss   Feb24   0:00
>> /lib/systemd/systemd-logind
>> root   978  0.0  0.2   2540  1084 ?SFeb24   0:00
>> /sbin/udevd
>> root   979  0.0  0.2   2540  1024 ?SFeb24   0:00
>> /sbin/udevd
>> root   884  0.0  0.1   5160   968 ?Ss   Feb24   0:00
>> /usr/sbin/sshd
>> root  5614  0.0  0.1   2484   916 pts/0R+   23:41   0:00 ps aux
>> --sort -rss
>> root  4918  0.0  0.1   1772   796 ?Ss   22:46   0:00
>> /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
>> root  5481  0.0  0.1   1772   796 ?Ss   23:32   0:00
>> /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
>> root   701  0.0  0.1   3344   716 tty1 Ss+  Feb24   0:00
>> /sbin/agetty tty1 38400
>> root   702  0.0  0.1   3164   712 ttyO0Ss+  Feb24   0:00
>> /sbin/agetty -s ttyO0 115200 38400 9600
>> root   890  0.0  0.1   3356   704 ?Ss   Feb24   0:01
>> /usr/sbin/cron
>> root   674  0.0  0.1   1332   684 ?Ss   Feb24   0:00
>> /usr/sbin/acpid
>> root  1010  0.0  0.1   1780   544 ?Ss   Feb24   0:00
>> /usr/sbin/udhcpd -S /etc/udhcpd.conf
>> avahi  717  0.0  0.0   2760   500 ?SFeb24   0:00
>> avahi-daemon: chroot helper
>>
>>
>> Do you know how can i find out who is using that much of memory ? Do you
>> think that it can be the kernel ? the log ?
>>
>> Micka,
>>
>>
>>
>>  --
> 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.
> 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+uns

Re: [beagleboard] GPIO pins and Device Trees with 3.14 kernel

[Peter Gregory]

Is PWM supported in kernel 3.14?
Is there some trick that will populate the /sys/class/PWM directory with export 
and other entries needed to configure PWM?
I see lots of examples for generic GPIO under 3.14 and they work fine.
However, all the PWM examples I see use 3.8 and cape manager and device 
overlays.

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

Re: [beagleboard] Custom Beaglebone black Audio cape with TLV320AIC3110

[John Syn]

From:  
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Thursday, November 13, 2014 at 5:46 PM
To:  "beagleboard@googlegroups.com" 
Cc:  
Subject:  [beagleboard] Custom Beaglebone black Audio cape with
TLV320AIC3110

> Hi,
> 
> I am trying to design a cape with TLV320AIC3110 for Beaglebone black using
> I2c2 and Mcasp0. I have compiled the driver into the kernel and modified the
> device tree. This is my procedure.
> 
> ubuntu@arm:~$ uname -r
> 3.15.10-bone8
> 
> 1- Driver:
> I am using the driver in /sound/soc/codecs/tlc320aic31xx.c
> diff --git a/sound/soc/codecs/tlv320aic31xx.c
> b/sound/soc/codecs/tlv320aic31xx.c
> index d1929de..1c300a5 100644
> --- a/sound/soc/codecs/tlv320aic31xx.c
> +++ b/sound/soc/codecs/tlv320aic31xx.c
> @@ -19,7 +19,7 @@
>   * high performance codec which provides a stereo DAC, a mono ADC,
>   * and mono/stereo Class-D speaker driver.
>   */
> -
> +#define DEBUG 
>  #include 
>  #include 
>  #include 
> 
> 2- Edit Kconfig
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index f0e8401..19036e3 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -461,7 +461,8 @@ config SND_SOC_TLV320AIC26
> depends on SPI
>  
>  config SND_SOC_TLV320AIC31XX
> -tristate
> +tristate "TI TLV320AIC31xx class D codecs"
> +   depends on I2C
>  
>  config SND_SOC_TLV320AIC32X4
> tristate
> 
> 
> 3- ALSA Machine Layer Configuration:
> Create a DAI (digital audio interface) Link structure. This should allow a
> specific configuration for the McASP to be called when Linux is directed to
> play audio to the TLV320AIC31XX. For Sitara McASP machine layer driver is
> found at sound/soc/davinci/davinci-evm.c
> 
> diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
> index cab98a5..41db457 100644
> --- a/sound/soc/davinci/davinci-evm.c
> +++ b/sound/soc/davinci/davinci-evm.c
> @@ -8,7 +8,7 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> -
> +#define DEBUG
>  #include 
>  #include 
>  #include 
> @@ -98,6 +98,13 @@ static const struct snd_soc_dapm_widget
> aic3x_dapm_widgets[]
> SND_SOC_DAPM_LINE("Line In", NULL),
>  };
>  
> +static const struct snd_soc_dapm_widget aic31xx_dapm_widgets[] = {
> +   SND_SOC_DAPM_HP("Headphone Jack", NULL),
> +   SND_SOC_DAPM_SPK("Speaker", NULL),
> +   SND_SOC_DAPM_MIC("Mic Jack", NULL),
> +};
> +
> +
>  /* davinci-evm machine audio_mapnections to the codec pins */
>  static const struct snd_soc_dapm_route audio_map[] = {
> /* Headphone connected to HPLOUT, HPROUT */
> @@ -120,6 +127,7 @@ static const struct snd_soc_dapm_route audio_map[] = {
> {"LINE2R", NULL, "Line In"},
>  };
>  
> +
>  /* Logic for a aic3x as connected on a davinci-evm */
>  static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
>  {
> @@ -150,6 +158,42 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime
> *rtd)
> return 0;
>  }
>  
> +/* Logic for a aic31xx as connected on a davinci-evm */
> +static int evm_aic31xx_init (struct snd_soc_pcm_runtime *rtd)
> +{
> +struct snd_soc_codec *codec = rtd->codec;
> +struct snd_soc_dapm_context *dapm = &codec->dapm;
> +struct device_node *np = codec->card->dev->of_node;
> +int ret;
> +
> +/* Add davinci-evm specific widgets */
> +snd_soc_dapm_new_controls(dapm, aic31xx_dapm_widgets,
> +  ARRAY_SIZE(aic31xx_dapm_widgets));
> +
> +if (np) {
> +ret = snd_soc_of_parse_audio_routing(codec->card,
> "ti,audio-rou
> +if (ret)
> +return ret;
> +} 
> +/*
> +else {
> +*/
> +/* Set up davinci-evm specific audio path audio_map */
> +/*
> +snd_soc_dapm_add_routes(&card->dapm, audio_map,
> +ARRAY_SIZE(audio_map));
> +}
> +*/
> +/* not connected */
> +/*snd_soc_dapm_nc_pin(&codec->dapm, "MONO_LOUT");
> +snd_soc_dapm_nc_pin(&codec->dapm, "HPLCOM");
> +snd_soc_dapm_nc_pin(&codec->dapm, "HPRCOM");
> +*/
> +return 0;
> +}
> +
> +
> +
>  /* davinci-evm digital audio interface glue - connects codec <--> CPU */
>  static struct snd_soc_dai_link dm6446_evm_dai = {
> .name = "TLV320AIC3X",
> @@ -250,6 +294,8 @@ static struct snd_soc_dai_link da850_evm_dai = {
>SND_SOC_DAIFMT_IB_NF,
>  };
>  
> +
> +
>  /* davinci dm6446 evm audio machine driver */
>  /*
>   * ASP0 in DM6446 EVM is clocked by U55, as configured by
> @@ -343,16 +389,33 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
> .stream_name= "AIC3X",
> .codec_dai_name = "tlv320aic3x-hifi",
> .ops= &evm_ops,
> -   .init   = evm_aic3x_init,
> +.init   = evm_aic3x_init,
> .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_

[beagleboard] Re: BBB boots on SD card, not from emmc. Any ideas?

[Vlad Ungureanu]

Hello,

Try https://github.com/ungureanuvladvictor/BBBlfs to flash directly the 
eMMC.

On Wednesday, November 12, 2014 11:42:59 PM UTC+1, Christopher Greer wrote:
>
>
> I've got a BBB (rev C) and I've been trying different images. As I was 
> learning to flash it, I've gotten one of the boards in a state where it 
> will boot off the microSD card, but not off the emmc. When there is no card 
> inserted into the BBB, the power LED comes on steady, but there is no 
> output on the serial terminal and none of the LEDs seem to work. However, 
> when booting from a SD card, everything seems to more or less behave.
>
> I haven't booted on the SD card and tried to access the emmc, since I'm 
> not entirely sure on how to do that. 
>
> I've attached the output of running a flasher SD card image that seems to 
> complete normally. The SDcard seems fine; I've used it to flash another BBB 
> just fine. The particular image on the SD card doesn't seem to matter 
> either.
>
> There is one section of the output that seems suspicious, which I've 
> copied from the attachment. It seems like the emmc partition table is 
> somehow corrupted? I'm new to this though, so I'll defer to anyone who 
> knows more.
>
> Thanks.
>
> -
> dd if=/opt/backup/uboot/u-boot.img of=/dev/mmcblk1 count=2 seek=1 
> conv=notrunc bs=384k
> -
> 0+1 records in
> 0+1 records out
> 375372 bytes (375 kB) copied, 0.0571357 s, 6.6 MB/s
> Formatting: /dev/mmcblk1
> Checking that no[   20.440917]  mmcblk1: unknown partition table
> -one is using this disk right now ...
> OK
>
> Dis[   20.451158]  mmcblk1: p1 p2
> k /dev/mmcblk1: 118016 cylinders, 4 heads, 16 sectors/track
>
> sfdisk: ERROR: sector 3069653513 does not have an msdos signature
>  /dev/mmcblk1: unrecognized partition table type
> Old situation:
> No partitions found
> New situation:
> Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
>
>Device Boot Start   EndMiB#blocks   Id  System
> /dev/mmcblk1p1   * 1 96 96  98304e  W95 FAT16 (LBA)
> /dev/mmcblk1p297   3687   35913677184   83  Linux
> /dev/mmcblk1p3 0  -  0  00  Empty
> /dev/mmcblk1p4 0  -  0  00  Empty
> Successfully wrote the new partition table
>
> Re-reading the partition table ...
>
> If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
> to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
> (See fdisk(8).)
> mkfs.vfat -F 16 /dev/mmcblk1p1 -n BEAGLEBONE
> -
> mkfs.vfat 3.0.13 (30 Jun 2012)
> -
> mkfs.ext4 /dev/mmcblk1p2 -L rootfs
> -
> mke2fs 1.42.5 (29-Jul-2012)
> ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing 
> mtab file while determining whether /dev/mmcblk1p2 is mounted.
> Discarding device blocks: done
> Filesystem label=rootfs
>

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

Re: [beagleboard] Size and name of FAT partition

[Alexander Rössler]

As temporary workaround it should work to modify the values in 
/opt/scripts/tools/init-eMMC-flasher.sh right?

Am Donnerstag, 13. November 2014 15:26:49 UTC+1 schrieb RobertCNelson:
>
> Hi Alexander, 
>
> This will take a few tweaks, give me a day or so 
>
> On Thu, Nov 13, 2014 at 4:47 AM, Alexander Rössler 
> > wrote: 
> > The Debian images include a fat partition for sharing drivers and 
> > documentation. Is there a way to increase the size of this partition? We 
> > would like to use the FAT partition to deploy our applications within 
> the 
> > product. 
> > 
> > I already tried using GParted to move the root partition and increasing 
> the 
> > FAT partition. Booting still worked. However, GParted was not able to 
> resize 
> > the FAT partition. 
>
> fat is hardcoded to 96Mb when "--beagleboard.org-production" is passed 
> to setup_sdcard.sh 
>
>
> https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L463
>  
>
> this value is copied (thru /boot/SOC.sh) and used by the flasher script: 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L399
>  
>
> So we just need an override for boot size... 
>
>
> > Renaming the partition is possible with GParted. However, for some 
> reason 
> > after flashing the image to the eMMC the name of the partition is 
> BEAGLEBONE 
> > again. Any idea how to solve that? 
>
> For the partition name, well this is hard coded in the flasher: 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L249
>  
>
> for setup_sdcard.sh we have the label option: "--boot_label" i just 
> need to pass it thru /boot/SOC.sh and pass it to the flasher.. 
>
>
> https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L1297
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Labolatory power supply fails to power up BeagleBone Black

[John Syn]

From:  Graham 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Friday, November 14, 2014 at 8:03 AM
To:  "beagleboard@googlegroups.com" 
Subject:  [beagleboard] Re: Labolatory power supply fails to power up
BeagleBone Black

> I have a similar problem, using a "B&K Precision 1550" Lab Bench Power Supply.
> When you turn on the Output of the supply, the BBB Power Light blinks once and
> the BeagleBone Black does not boot.
> 
> If you put an oscilloscope on the output of the supply and watch it turn on,
> then
> the power supply overshoots up to 6 Volts, before returning to the 5 Volt
> setting.
That is just crazy. I have never seen a bench power supply do this. Perhaps
you should contact B&K, because there must be something wrong with the
voltage regulation on your power supply.

Regards,
John
> 
> 
> It turns out that the Power Management IC used in the Beaglebone Black will
> do an over-voltage shutdown at 6 Volts for protection. So, that is why it does
> one-blink then shuts-off.
> 
> So, not only do you need a certain rise time, which the B&K power supply
> meets, but  you can not have any large overshoot.  No good power supply
> should have this much overshoot, but the B&K does, so it has problems
> running a BBB.
> 
> --- Graham
> 
> ==
> 
> On Friday, November 14, 2014 4:03:37 AM UTC-6, bremenpl wrote:
>> Hello there,
>> I have a very strange problem with powering up BeagleBone Black (rev C)
>> When i try to power it up from some cheap AC adapter it works fine, but when
>> I connect to to my labolatory power supply the power LED on board is lid for
>> a second and then doesnt power up the MCU and turns off intead. I have
>> connected both supplys to osciloscope and they are both stable, the
>> laboratory one even more. Why is the power controller on the BeagleBone Black
>> refusing to power up the MCU when powered from lab supply? I have no idea
>> what is this about. I would aprichiate 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[John Syn]

From:  evilwulfie 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Friday, November 14, 2014 at 5:48 AM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Labolatory power supply fails to power up
BeagleBone Black

> 
>  
> As Gerald has said before, check the ramp up of the power supply.
>  Some of the lab supplys have slow ramp ups.
>  Yes they are very stable and VERY good regulation but
>  the BBB design requires a fast ramp up supply.
It could also be that he has current limit set too low. Set the current
limit to 2A or more. It would be helpful if we could see an oscilloscope
capture of the startup waveform.

Regards,
John
> 
>  
>  
>  
>  On 11/14/2014 3:03 AM, bremenpl wrote:
>  
>  
>>  
>> Hello there,
>>  I have a very strange problem with powering up BeagleBone Black (rev C)
>> When i try to power it up from some cheap AC adapter it works fine, but when
>> I connect to to my labolatory power supply the power LED on board is lid for
>> a second and then doesnt power up the MCU and turns off intead. I have
>> connected both supplys to osciloscope and they are both stable, the
>> laboratory one even more. Why is the power controller on the BeagleBone Black
>> refusing to power up the MCU when powered from lab supply? I have no idea
>> what is this about. I would aprichiate 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.
>>  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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Running MIDI IN / MIDI OUT from BBB ?

[henrique matias]

Hello Guys,

I could not find instructions to implement MIDI IN / OUT with BBB..

I found some threads saying the MIDI cape will be released on the 3rd
quarter, but i'm guessing there is a way of implementing without having the
cape?

I did a couple of tests with Arduino before and i just had to import the
MIDI library and it was ready to go..

Any tips on how to get this going? Needless to say Using node/npm would be
sweet!


Thank you very much



-- 
*time isn't passing, it's you passing.*

❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂
❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁ ❂ ❁

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

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

A question regarding battery though- if i leave the bbb under battery 
supply, but turn off the mcu with pwr button, what will be the current 
drawn by TPS chip? Wont it dry the battery through the night? Lets say its 
a single li-ion cell 2200mAh



Dnia 14 listopada 2014 16:41:30 Gerald Coley  
napisał(a):



The output voltage level is different. When the DC is contented it is
supposed to go to the DC input and go into charge mode for the battery.
Measure the output voltage of the PMIC. If it is 5V, then it is DC in. If
it is 3.7V +/- then it is running on the battery.

Gerald


On Fri, Nov 14, 2014 at 9:37 AM, Bremenpl  wrote:

>   How can I know either it switched without taking the battery out?
>
> Dnia 14 listopada 2014 16:35:42 Gerald Coley 
> napisał(a):
>
>> Another test here would be to connect the battery and see if after it
>> switches to the battery if it switches back to the DC input.
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 9:31 AM, Bremenpl  wrote:
>>
>>>   I understand, thank you for the info. I will make more attempts at
>>> monday with another bbb board. For now I have a 10k resistor on the TS pin
>>> because I intend to use the battery to. If the voltage is measured on the
>>> resistor ill swap it to lower value one. I hope ill get it working using
>>> meanwell power supply.
>>>
>>> Dnia 14 listopada 2014 16:16:30 Gerald Coley 
>>> napisał(a):
>>>
 Not likely. As I said we need more boards that fail and the power
 supply that is used with them. What I have seen is that it tries to switch
 to the battery, that is not there, for whatever reason. Theory is it 
sees a

 voltage drop due to the inrush limit on certain power supplies. I have
 fixed this on a few boards by connecting the TS signal hard to ground 
using

 the battery pins on the board.

 What I see when the board "does not power up" is the PMIC cycling on
 and off. You can look at the 5V output rail of the PMIC for this 
condition.


 Gerald


 On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:

>   I dont agree here, and this is the weird part. A cheap 5V wall plug
> adapter works great and a certified meanwell supply does not. Can it be a
> case related to linear/ switching power supply?
>
> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
> napisał(a):
>
>> We are working on one if we can collect enough information to confirm
>> the issue. it appears to be a power supply issue that creates a 
condition
>> that the TPS65217C does not like. If you use a good power supply, 
the issue

>> is not there.
>>
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:
>>
>>>  Is there a workaround for this? I thought that pre charged
>>> capacitors could help but in my application power to the BeagleBone 
Black

>>> is aplied in the same time as to the rest of the circuit.
>>>
>>> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>>>
>>> The power management IC, TPS65217C.
>>>
>>>  Gerald
>>>
>>>
>>> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl 
>>> wrote:
>>>
  What is the exact circuit that requires a fast ramp?

 W dniu 2014-11-14 o 14:48, evilwulfie pisze:

 As Gerald has said before, check the ramp up of the power supply.
 Some of the lab supplys have slow ramp ups.
 Yes they are very stable and VERY good regulation but
 the BBB design requires a fast ramp up supply.



 On 11/14/2014 3:03 AM, bremenpl wrote:

 Hello there,
 I have a very strange problem with powering up BeagleBone Black
 (rev C) When i try to power it up from some cheap AC adapter 
it works
 fine, but when I connect to to my labolatory power supply the 
power LED on
 board is lid for a second and then doesnt power up the MCU and 
turns off

 intead. I have connected both supplys to osciloscope and they are both
 stable, the laboratory one even more. Why is the power controller 
on the
 BeagleBone Black refusing to power up the MCU when powered from 
lab supply?

 I have no idea what is this about. I would aprichiate 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.
 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 a topic in
 the Google Groups "BeagleBoard" group.
 To unsubscribe from th

[beagleboard] Re: Labolatory power supply fails to power up BeagleBone Black

[Graham]

I have a similar problem, using a "B&K Precision 1550" Lab Bench Power 
Supply.
When you turn on the Output of the supply, the BBB Power Light blinks once 
and 
the BeagleBone Black does not boot. 

If you put an oscilloscope on the output of the supply and watch it turn 
on, then
the power supply overshoots up to 6 Volts, before returning to the 5 Volt 
setting.

It turns out that the Power Management IC used in the Beaglebone Black will
do an over-voltage shutdown at 6 Volts for protection. So, that is why it 
does
one-blink then shuts-off.

So, not only do you need a certain rise time, which the B&K power supply 
meets, but  you can not have any large overshoot.  No good power supply
should have this much overshoot, but the B&K does, so it has problems
running a BBB.

--- Graham

==

On Friday, November 14, 2014 4:03:37 AM UTC-6, bremenpl wrote:
>
> Hello there,
> I have a very strange problem with powering up BeagleBone Black (rev 
> C) When i try to power it up from some cheap AC adapter it works fine, 
> but when I connect to to my labolatory power supply the power LED on board 
> is lid for a second and then doesnt power up the MCU and turns off intead. 
> I have connected both supplys to osciloscope and they are both stable, the 
> laboratory one even more. Why is the power controller on the BeagleBone 
> Black refusing to power up the MCU when powered from lab supply? I have no 
> idea what is this about. I would aprichiate 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

And mine.

Gerald

On Fri, Nov 14, 2014 at 9:50 AM, Bremenpl  wrote:

>   Ill get it tested, thank you. If this worked it would solve my problem.
>
> Dnia 14 listopada 2014 16:41:30 Gerald Coley 
> napisał(a):
>
>> The output voltage level is different. When the DC is contented it is
>> supposed to go to the DC input and go into charge mode for the battery.
>> Measure the output voltage of the PMIC. If it is 5V, then it is DC in. If
>> it is 3.7V +/- then it is running on the battery.
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 9:37 AM, Bremenpl  wrote:
>>
>>>   How can I know either it switched without taking the battery out?
>>>
>>> Dnia 14 listopada 2014 16:35:42 Gerald Coley 
>>> napisał(a):
>>>
 Another test here would be to connect the battery and see if after it
 switches to the battery if it switches back to the DC input.

 Gerald


 On Fri, Nov 14, 2014 at 9:31 AM, Bremenpl  wrote:

>   I understand, thank you for the info. I will make more attempts at
> monday with another bbb board. For now I have a 10k resistor on the TS pin
> because I intend to use the battery to. If the voltage is measured on the
> resistor ill swap it to lower value one. I hope ill get it working using
> meanwell power supply.
>
> Dnia 14 listopada 2014 16:16:30 Gerald Coley 
> napisał(a):
>
>> Not likely. As I said we need more boards that fail and the power
>> supply that is used with them. What I have seen is that it tries to 
>> switch
>> to the battery, that is not there, for whatever reason. Theory is it 
>> sees a
>> voltage drop due to the inrush limit on certain power supplies. I have
>> fixed this on a few boards by connecting the TS signal hard to ground 
>> using
>> the battery pins on the board.
>>
>> What I see when the board "does not power up" is the PMIC cycling on
>> and off. You can look at the 5V output rail of the PMIC for this 
>> condition.
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:
>>
>>>   I dont agree here, and this is the weird part. A cheap 5V wall
>>> plug adapter works great and a certified meanwell supply does not. Can 
>>> it
>>> be a case related to linear/ switching power supply?
>>>
>>> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
>>> napisał(a):
>>>
 We are working on one if we can collect enough information to
 confirm the issue. it appears to be a power supply issue that creates a
 condition that the TPS65217C does not like. If you use a good power 
 supply,
 the issue is not there.


 Gerald


 On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl 
 wrote:

>  Is there a workaround for this? I thought that pre charged
> capacitors could help but in my application power to the BeagleBone 
> Black
> is aplied in the same time as to the rest of the circuit.
>
> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>
> The power management IC, TPS65217C.
>
>  Gerald
>
>
> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl 
> wrote:
>
>>  What is the exact circuit that requires a fast ramp?
>>
>> W dniu 2014-11-14 o 14:48, evilwulfie pisze:
>>
>> As Gerald has said before, check the ramp up of the power supply.
>> Some of the lab supplys have slow ramp ups.
>> Yes they are very stable and VERY good regulation but
>> the BBB design requires a fast ramp up supply.
>>
>>
>>
>> On 11/14/2014 3:03 AM, bremenpl wrote:
>>
>> Hello there,
>> I have a very strange problem with powering up BeagleBone Black
>> (rev C) When i try to power it up from some cheap AC adapter it 
>> works
>> fine, but when I connect to to my labolatory power supply the power 
>> LED on
>> board is lid for a second and then doesnt power up the MCU and turns 
>> off
>> intead. I have connected both supplys to osciloscope and they are 
>> both
>> stable, the laboratory one even more. Why is the power controller on 
>> the
>> BeagleBone Black refusing to power up the MCU when powered from lab 
>> supply?
>> I have no idea what is this about. I would aprichiate 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.
>> For more options, visit https://groups.google.com/d/optout.
>>

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

Ill get it tested, thank you. If this worked it would solve my problem.


Dnia 14 listopada 2014 16:41:30 Gerald Coley  
napisał(a):



The output voltage level is different. When the DC is contented it is
supposed to go to the DC input and go into charge mode for the battery.
Measure the output voltage of the PMIC. If it is 5V, then it is DC in. If
it is 3.7V +/- then it is running on the battery.

Gerald


On Fri, Nov 14, 2014 at 9:37 AM, Bremenpl  wrote:

>   How can I know either it switched without taking the battery out?
>
> Dnia 14 listopada 2014 16:35:42 Gerald Coley 
> napisał(a):
>
>> Another test here would be to connect the battery and see if after it
>> switches to the battery if it switches back to the DC input.
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 9:31 AM, Bremenpl  wrote:
>>
>>>   I understand, thank you for the info. I will make more attempts at
>>> monday with another bbb board. For now I have a 10k resistor on the TS pin
>>> because I intend to use the battery to. If the voltage is measured on the
>>> resistor ill swap it to lower value one. I hope ill get it working using
>>> meanwell power supply.
>>>
>>> Dnia 14 listopada 2014 16:16:30 Gerald Coley 
>>> napisał(a):
>>>
 Not likely. As I said we need more boards that fail and the power
 supply that is used with them. What I have seen is that it tries to switch
 to the battery, that is not there, for whatever reason. Theory is it 
sees a

 voltage drop due to the inrush limit on certain power supplies. I have
 fixed this on a few boards by connecting the TS signal hard to ground 
using

 the battery pins on the board.

 What I see when the board "does not power up" is the PMIC cycling on
 and off. You can look at the 5V output rail of the PMIC for this 
condition.


 Gerald


 On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:

>   I dont agree here, and this is the weird part. A cheap 5V wall plug
> adapter works great and a certified meanwell supply does not. Can it be a
> case related to linear/ switching power supply?
>
> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
> napisał(a):
>
>> We are working on one if we can collect enough information to confirm
>> the issue. it appears to be a power supply issue that creates a 
condition
>> that the TPS65217C does not like. If you use a good power supply, 
the issue

>> is not there.
>>
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:
>>
>>>  Is there a workaround for this? I thought that pre charged
>>> capacitors could help but in my application power to the BeagleBone 
Black

>>> is aplied in the same time as to the rest of the circuit.
>>>
>>> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>>>
>>> The power management IC, TPS65217C.
>>>
>>>  Gerald
>>>
>>>
>>> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl 
>>> wrote:
>>>
  What is the exact circuit that requires a fast ramp?

 W dniu 2014-11-14 o 14:48, evilwulfie pisze:

 As Gerald has said before, check the ramp up of the power supply.
 Some of the lab supplys have slow ramp ups.
 Yes they are very stable and VERY good regulation but
 the BBB design requires a fast ramp up supply.



 On 11/14/2014 3:03 AM, bremenpl wrote:

 Hello there,
 I have a very strange problem with powering up BeagleBone Black
 (rev C) When i try to power it up from some cheap AC adapter 
it works
 fine, but when I connect to to my labolatory power supply the 
power LED on
 board is lid for a second and then doesnt power up the MCU and 
turns off

 intead. I have connected both supplys to osciloscope and they are both
 stable, the laboratory one even more. Why is the power controller 
on the
 BeagleBone Black refusing to power up the MCU when powered from 
lab supply?

 I have no idea what is this about. I would aprichiate 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.
 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 a topic in
 the Google Groups "BeagleBoard" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an em

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

How can I know either it switched without taking the battery out?


Dnia 14 listopada 2014 16:35:42 Gerald Coley  
napisał(a):



Another test here would be to connect the battery and see if after it
switches to the battery if it switches back to the DC input.

Gerald


On Fri, Nov 14, 2014 at 9:31 AM, Bremenpl  wrote:

>   I understand, thank you for the info. I will make more attempts at
> monday with another bbb board. For now I have a 10k resistor on the TS pin
> because I intend to use the battery to. If the voltage is measured on the
> resistor ill swap it to lower value one. I hope ill get it working using
> meanwell power supply.
>
> Dnia 14 listopada 2014 16:16:30 Gerald Coley 
> napisał(a):
>
>> Not likely. As I said we need more boards that fail and the power supply
>> that is used with them. What I have seen is that it tries to switch to the
>> battery, that is not there, for whatever reason. Theory is it sees a
>> voltage drop due to the inrush limit on certain power supplies. I have
>> fixed this on a few boards by connecting the TS signal hard to ground using
>> the battery pins on the board.
>>
>> What I see when the board "does not power up" is the PMIC cycling on and
>> off. You can look at the 5V output rail of the PMIC for this condition.
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:
>>
>>>   I dont agree here, and this is the weird part. A cheap 5V wall plug
>>> adapter works great and a certified meanwell supply does not. Can it be a
>>> case related to linear/ switching power supply?
>>>
>>> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
>>> napisał(a):
>>>
 We are working on one if we can collect enough information to confirm
 the issue. it appears to be a power supply issue that creates a condition
 that the TPS65217C does not like. If you use a good power supply, the 
issue

 is not there.


 Gerald


 On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:

>  Is there a workaround for this? I thought that pre charged capacitors
> could help but in my application power to the BeagleBone Black is 
aplied in

> the same time as to the rest of the circuit.
>
> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>
> The power management IC, TPS65217C.
>
>  Gerald
>
>
> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl  wrote:
>
>>  What is the exact circuit that requires a fast ramp?
>>
>> W dniu 2014-11-14 o 14:48, evilwulfie pisze:
>>
>> As Gerald has said before, check the ramp up of the power supply.
>> Some of the lab supplys have slow ramp ups.
>> Yes they are very stable and VERY good regulation but
>> the BBB design requires a fast ramp up supply.
>>
>>
>>
>> On 11/14/2014 3:03 AM, bremenpl wrote:
>>
>> Hello there,
>> I have a very strange problem with powering up BeagleBone Black (rev
>> C) When i try to power it up from some cheap AC adapter it works 
fine,
>> but when I connect to to my labolatory power supply the power LED on 
board
>> is lid for a second and then doesnt power up the MCU and turns off 
intead.
>> I have connected both supplys to osciloscope and they are both 
stable, the

>> laboratory one even more. Why is the power controller on the BeagleBone
>> Black refusing to power up the MCU when powered from lab supply? I 
have no

>> idea what is this about. I would aprichiate 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.
>> 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 a topic in
>> the Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Bremenpl
>>
>>   --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>  --
>   Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>  http

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

The output voltage level is different. When the DC is contented it is
supposed to go to the DC input and go into charge mode for the battery.
Measure the output voltage of the PMIC. If it is 5V, then it is DC in. If
it is 3.7V +/- then it is running on the battery.

Gerald


On Fri, Nov 14, 2014 at 9:37 AM, Bremenpl  wrote:

>   How can I know either it switched without taking the battery out?
>
> Dnia 14 listopada 2014 16:35:42 Gerald Coley 
> napisał(a):
>
>> Another test here would be to connect the battery and see if after it
>> switches to the battery if it switches back to the DC input.
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 9:31 AM, Bremenpl  wrote:
>>
>>>   I understand, thank you for the info. I will make more attempts at
>>> monday with another bbb board. For now I have a 10k resistor on the TS pin
>>> because I intend to use the battery to. If the voltage is measured on the
>>> resistor ill swap it to lower value one. I hope ill get it working using
>>> meanwell power supply.
>>>
>>> Dnia 14 listopada 2014 16:16:30 Gerald Coley 
>>> napisał(a):
>>>
 Not likely. As I said we need more boards that fail and the power
 supply that is used with them. What I have seen is that it tries to switch
 to the battery, that is not there, for whatever reason. Theory is it sees a
 voltage drop due to the inrush limit on certain power supplies. I have
 fixed this on a few boards by connecting the TS signal hard to ground using
 the battery pins on the board.

 What I see when the board "does not power up" is the PMIC cycling on
 and off. You can look at the 5V output rail of the PMIC for this condition.

 Gerald


 On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:

>   I dont agree here, and this is the weird part. A cheap 5V wall plug
> adapter works great and a certified meanwell supply does not. Can it be a
> case related to linear/ switching power supply?
>
> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
> napisał(a):
>
>> We are working on one if we can collect enough information to confirm
>> the issue. it appears to be a power supply issue that creates a condition
>> that the TPS65217C does not like. If you use a good power supply, the 
>> issue
>> is not there.
>>
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:
>>
>>>  Is there a workaround for this? I thought that pre charged
>>> capacitors could help but in my application power to the BeagleBone 
>>> Black
>>> is aplied in the same time as to the rest of the circuit.
>>>
>>> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>>>
>>> The power management IC, TPS65217C.
>>>
>>>  Gerald
>>>
>>>
>>> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl 
>>> wrote:
>>>
  What is the exact circuit that requires a fast ramp?

 W dniu 2014-11-14 o 14:48, evilwulfie pisze:

 As Gerald has said before, check the ramp up of the power supply.
 Some of the lab supplys have slow ramp ups.
 Yes they are very stable and VERY good regulation but
 the BBB design requires a fast ramp up supply.



 On 11/14/2014 3:03 AM, bremenpl wrote:

 Hello there,
 I have a very strange problem with powering up BeagleBone Black
 (rev C) When i try to power it up from some cheap AC adapter it 
 works
 fine, but when I connect to to my labolatory power supply the power 
 LED on
 board is lid for a second and then doesnt power up the MCU and turns 
 off
 intead. I have connected both supplys to osciloscope and they are both
 stable, the laboratory one even more. Why is the power controller on 
 the
 BeagleBone Black refusing to power up the MCU when powered from lab 
 supply?
 I have no idea what is this about. I would aprichiate 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.
 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 a topic in
 the Google Groups "BeagleBoard" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, vis

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

Another test here would be to connect the battery and see if after it
switches to the battery if it switches back to the DC input.

Gerald


On Fri, Nov 14, 2014 at 9:31 AM, Bremenpl  wrote:

>   I understand, thank you for the info. I will make more attempts at
> monday with another bbb board. For now I have a 10k resistor on the TS pin
> because I intend to use the battery to. If the voltage is measured on the
> resistor ill swap it to lower value one. I hope ill get it working using
> meanwell power supply.
>
> Dnia 14 listopada 2014 16:16:30 Gerald Coley 
> napisał(a):
>
>> Not likely. As I said we need more boards that fail and the power supply
>> that is used with them. What I have seen is that it tries to switch to the
>> battery, that is not there, for whatever reason. Theory is it sees a
>> voltage drop due to the inrush limit on certain power supplies. I have
>> fixed this on a few boards by connecting the TS signal hard to ground using
>> the battery pins on the board.
>>
>> What I see when the board "does not power up" is the PMIC cycling on and
>> off. You can look at the 5V output rail of the PMIC for this condition.
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:
>>
>>>   I dont agree here, and this is the weird part. A cheap 5V wall plug
>>> adapter works great and a certified meanwell supply does not. Can it be a
>>> case related to linear/ switching power supply?
>>>
>>> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
>>> napisał(a):
>>>
 We are working on one if we can collect enough information to confirm
 the issue. it appears to be a power supply issue that creates a condition
 that the TPS65217C does not like. If you use a good power supply, the issue
 is not there.


 Gerald


 On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:

>  Is there a workaround for this? I thought that pre charged capacitors
> could help but in my application power to the BeagleBone Black is aplied 
> in
> the same time as to the rest of the circuit.
>
> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>
> The power management IC, TPS65217C.
>
>  Gerald
>
>
> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl  wrote:
>
>>  What is the exact circuit that requires a fast ramp?
>>
>> W dniu 2014-11-14 o 14:48, evilwulfie pisze:
>>
>> As Gerald has said before, check the ramp up of the power supply.
>> Some of the lab supplys have slow ramp ups.
>> Yes they are very stable and VERY good regulation but
>> the BBB design requires a fast ramp up supply.
>>
>>
>>
>> On 11/14/2014 3:03 AM, bremenpl wrote:
>>
>> Hello there,
>> I have a very strange problem with powering up BeagleBone Black (rev
>> C) When i try to power it up from some cheap AC adapter it works 
>> fine,
>> but when I connect to to my labolatory power supply the power LED on 
>> board
>> is lid for a second and then doesnt power up the MCU and turns off 
>> intead.
>> I have connected both supplys to osciloscope and they are both stable, 
>> the
>> laboratory one even more. Why is the power controller on the BeagleBone
>> Black refusing to power up the MCU when powered from lab supply? I have 
>> no
>> idea what is this about. I would aprichiate 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.
>> 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 a topic in
>> the Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Bremenpl
>>
>>   --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>  --
>   Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>  http://circuitco.com/support/
>   --
> For more options, visit http://beagleboard.org/discu

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

I understand, thank you for the info. I will make more attempts at monday 
with another bbb board. For now I have a 10k resistor on the TS pin because 
I intend to use the battery to. If the voltage is measured on the resistor 
ill swap it to lower value one. I hope ill get it working using meanwell 
power supply.



Dnia 14 listopada 2014 16:16:30 Gerald Coley  
napisał(a):



Not likely. As I said we need more boards that fail and the power supply
that is used with them. What I have seen is that it tries to switch to the
battery, that is not there, for whatever reason. Theory is it sees a
voltage drop due to the inrush limit on certain power supplies. I have
fixed this on a few boards by connecting the TS signal hard to ground using
the battery pins on the board.

What I see when the board "does not power up" is the PMIC cycling on and
off. You can look at the 5V output rail of the PMIC for this condition.

Gerald


On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:

>   I dont agree here, and this is the weird part. A cheap 5V wall plug
> adapter works great and a certified meanwell supply does not. Can it be a
> case related to linear/ switching power supply?
>
> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
> napisał(a):
>
>> We are working on one if we can collect enough information to confirm the
>> issue. it appears to be a power supply issue that creates a condition that
>> the TPS65217C does not like. If you use a good power supply, the issue is
>> not there.
>>
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:
>>
>>>  Is there a workaround for this? I thought that pre charged capacitors
>>> could help but in my application power to the BeagleBone Black is aplied in
>>> the same time as to the rest of the circuit.
>>>
>>> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>>>
>>> The power management IC, TPS65217C.
>>>
>>>  Gerald
>>>
>>>
>>> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl  wrote:
>>>
  What is the exact circuit that requires a fast ramp?

 W dniu 2014-11-14 o 14:48, evilwulfie pisze:

 As Gerald has said before, check the ramp up of the power supply.
 Some of the lab supplys have slow ramp ups.
 Yes they are very stable and VERY good regulation but
 the BBB design requires a fast ramp up supply.



 On 11/14/2014 3:03 AM, bremenpl wrote:

 Hello there,
 I have a very strange problem with powering up BeagleBone Black (rev
 C) When i try to power it up from some cheap AC adapter it works fine,
 but when I connect to to my labolatory power supply the power LED on board
 is lid for a second and then doesnt power up the MCU and turns off intead.
 I have connected both supplys to osciloscope and they are both stable, the
 laboratory one even more. Why is the power controller on the BeagleBone
 Black refusing to power up the MCU when powered from lab supply? I have no
 idea what is this about. I would aprichiate 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.
 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 a topic in the
 Google Groups "BeagleBoard" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


 --
 Bremenpl

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

>>>
>>>
>>>
>>>  --
>>>   Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>  http://circuitco.com/support/
>>>   --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Bremenpl
>>>
>>>  --
>>> For more options, visit 

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

Not likely. As I said we need more boards that fail and the power supply
that is used with them. What I have seen is that it tries to switch to the
battery, that is not there, for whatever reason. Theory is it sees a
voltage drop due to the inrush limit on certain power supplies. I have
fixed this on a few boards by connecting the TS signal hard to ground using
the battery pins on the board.

What I see when the board "does not power up" is the PMIC cycling on and
off. You can look at the 5V output rail of the PMIC for this condition.

Gerald


On Fri, Nov 14, 2014 at 9:03 AM, Bremenpl  wrote:

>   I dont agree here, and this is the weird part. A cheap 5V wall plug
> adapter works great and a certified meanwell supply does not. Can it be a
> case related to linear/ switching power supply?
>
> Dnia 14 listopada 2014 16:01:26 Gerald Coley 
> napisał(a):
>
>> We are working on one if we can collect enough information to confirm the
>> issue. it appears to be a power supply issue that creates a condition that
>> the TPS65217C does not like. If you use a good power supply, the issue is
>> not there.
>>
>>
>> Gerald
>>
>>
>> On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:
>>
>>>  Is there a workaround for this? I thought that pre charged capacitors
>>> could help but in my application power to the BeagleBone Black is aplied in
>>> the same time as to the rest of the circuit.
>>>
>>> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>>>
>>> The power management IC, TPS65217C.
>>>
>>>  Gerald
>>>
>>>
>>> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl  wrote:
>>>
  What is the exact circuit that requires a fast ramp?

 W dniu 2014-11-14 o 14:48, evilwulfie pisze:

 As Gerald has said before, check the ramp up of the power supply.
 Some of the lab supplys have slow ramp ups.
 Yes they are very stable and VERY good regulation but
 the BBB design requires a fast ramp up supply.



 On 11/14/2014 3:03 AM, bremenpl wrote:

 Hello there,
 I have a very strange problem with powering up BeagleBone Black (rev
 C) When i try to power it up from some cheap AC adapter it works fine,
 but when I connect to to my labolatory power supply the power LED on board
 is lid for a second and then doesnt power up the MCU and turns off intead.
 I have connected both supplys to osciloscope and they are both stable, the
 laboratory one even more. Why is the power controller on the BeagleBone
 Black refusing to power up the MCU when powered from lab supply? I have no
 idea what is this about. I would aprichiate 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.
 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 a topic in the
 Google Groups "BeagleBoard" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


 --
 Bremenpl

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

>>>
>>>
>>>
>>>  --
>>>   Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>  http://circuitco.com/support/
>>>   --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Bremenpl
>>>
>>>  --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@

[beagleboard] Re: BBB Standby when press power button ?

[Peter Gregory]

You can power off the beaglebone by holding the power button for about 4 seconds
Clicking it after will power it back up.

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

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

I dont agree here, and this is the weird part. A cheap 5V wall plug adapter 
works great and a certified meanwell supply does not. Can it be a case 
related to linear/ switching power supply?



Dnia 14 listopada 2014 16:01:26 Gerald Coley  
napisał(a):



We are working on one if we can collect enough information to confirm the
issue. it appears to be a power supply issue that creates a condition that
the TPS65217C does not like. If you use a good power supply, the issue is
not there.


Gerald


On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:

>  Is there a workaround for this? I thought that pre charged capacitors
> could help but in my application power to the BeagleBone Black is aplied in
> the same time as to the rest of the circuit.
>
> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>
> The power management IC, TPS65217C.
>
>  Gerald
>
>
> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl  wrote:
>
>>  What is the exact circuit that requires a fast ramp?
>>
>> W dniu 2014-11-14 o 14:48, evilwulfie pisze:
>>
>> As Gerald has said before, check the ramp up of the power supply.
>> Some of the lab supplys have slow ramp ups.
>> Yes they are very stable and VERY good regulation but
>> the BBB design requires a fast ramp up supply.
>>
>>
>>
>> On 11/14/2014 3:03 AM, bremenpl wrote:
>>
>> Hello there,
>> I have a very strange problem with powering up BeagleBone Black (rev
>> C) When i try to power it up from some cheap AC adapter it works fine,
>> but when I connect to to my labolatory power supply the power LED on board
>> is lid for a second and then doesnt power up the MCU and turns off intead.
>> I have connected both supplys to osciloscope and they are both stable, the
>> laboratory one even more. Why is the power controller on the BeagleBone
>> Black refusing to power up the MCU when powered from lab supply? I have no
>> idea what is this about. I would aprichiate 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.
>> 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Bremenpl
>>
>>   --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>  --
>   Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>  http://circuitco.com/support/
>   --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Bremenpl
>
>  --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



--
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the 
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

We are working on one if we can collect enough information to confirm the
issue. it appears to be a power supply issue that creates a condition that
the TPS65217C does not like. If you use a good power supply, the issue is
not there.


Gerald


On Fri, Nov 14, 2014 at 8:31 AM, Bremenpl  wrote:

>  Is there a workaround for this? I thought that pre charged capacitors
> could help but in my application power to the BeagleBone Black is aplied in
> the same time as to the rest of the circuit.
>
> W dniu 2014-11-14 o 15:19, Gerald Coley pisze:
>
> The power management IC, TPS65217C.
>
>  Gerald
>
>
> On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl  wrote:
>
>>  What is the exact circuit that requires a fast ramp?
>>
>> W dniu 2014-11-14 o 14:48, evilwulfie pisze:
>>
>> As Gerald has said before, check the ramp up of the power supply.
>> Some of the lab supplys have slow ramp ups.
>> Yes they are very stable and VERY good regulation but
>> the BBB design requires a fast ramp up supply.
>>
>>
>>
>> On 11/14/2014 3:03 AM, bremenpl wrote:
>>
>> Hello there,
>> I have a very strange problem with powering up BeagleBone Black (rev
>> C) When i try to power it up from some cheap AC adapter it works fine,
>> but when I connect to to my labolatory power supply the power LED on board
>> is lid for a second and then doesnt power up the MCU and turns off intead.
>> I have connected both supplys to osciloscope and they are both stable, the
>> laboratory one even more. Why is the power controller on the BeagleBone
>> Black refusing to power up the MCU when powered from lab supply? I have no
>> idea what is this about. I would aprichiate 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.
>> 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Bremenpl
>>
>>   --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>  --
>   Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>  http://circuitco.com/support/
>   --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Bremenpl
>
>  --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

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

[beagleboard] Re: BBB Standby when press power button ?

[Richard St-Pierre]

Some ideas here... 

http://inspire.logicsupply.com/2014/08/beaglebone-unleash-your-beaglebone.html



On Thursday, November 13, 2014 10:59:53 PM UTC-5, Minh Phuong Dang wrote:
>
> Hello,
>
>   Ho to let BBB standby and wake up by pressing power button ?
>   I want to make a hand held device using BBB with Li-ion battery 
>   and I want power button acts like smart phone device does.
> 
>   Now I'm using :
>   
>  Android : TI-Android-JB-4.2.2-DevKit-4.1.1
>  Kernel   : linux-3.2.0
>
>   Thank you very much.
>
>   Phuong Dang 
>  
>

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

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

Is there a workaround for this? I thought that pre charged capacitors 
could help but in my application power to the BeagleBone Black is aplied 
in the same time as to the rest of the circuit.


W dniu 2014-11-14 o 15:19, Gerald Coley pisze:

The power management IC, TPS65217C.

Gerald


On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl > wrote:


What is the exact circuit that requires a fast ramp?

W dniu 2014-11-14 o 14:48, evilwulfie pisze:

As Gerald has said before, check the ramp up of the power supply.
Some of the lab supplys have slow ramp ups.
Yes they are very stable and VERY good regulation but
the BBB design requires a fast ramp up supply.



On 11/14/2014 3:03 AM, bremenpl wrote:

Hello there,
I have a very strange problem with powering up BeagleBone Black
(rev C) When i try to power it up from some cheap AC adapter
it works fine, but when I connect to to my labolatory power
supply the power LED on board is lid for a second and then
doesnt power up the MCU and turns off intead. I have connected
both supplys to osciloscope and they are both stable, the
laboratory one even more. Why is the power controller on the
BeagleBone Black refusing to power up the MCU when powered from
lab supply? I have no idea what is this about. I would
aprichiate 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
.
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 a topic
in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to beagleboard+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


-- 
Bremenpl


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




--
Gerald
ger...@beagleboard.org 
http://beagleboard.org/
http://circuitco.com/support/
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the 
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
Bremenpl

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

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Hi Michael,

Am Freitag, 14. November 2014 01:08:42 UTC+1 schrieb elt...@gmail.com:
>
> Hey,
>
> I'm trying to match the below modification in my version of libpruio, but 
> while compiling I run into the following
>
> ld: pruio.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can 
> not be used when making a shared object; recompile with -fPIC
>
> and I'm not sure how to get past it. I -think- that I have the freebasic 
> compiler running correctly. Any advice would be welcome.
>
> Thanks,
> Michael Todd
>
 
if you want to compile with the old (experimental) BBB-fbc-0.90 you'll have 
to use the old build scripts included in libpruio-0.0.x.

But I recommend to install the new BBB_fbc-1.00, which I also use on my 
board now. Just follow the instructions in (only point 1)

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_preparation.html#SecInstallation

BR

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

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

The power management IC, TPS65217C.

Gerald


On Fri, Nov 14, 2014 at 8:15 AM, Bremenpl  wrote:

>  What is the exact circuit that requires a fast ramp?
>
> W dniu 2014-11-14 o 14:48, evilwulfie pisze:
>
> As Gerald has said before, check the ramp up of the power supply.
> Some of the lab supplys have slow ramp ups.
> Yes they are very stable and VERY good regulation but
> the BBB design requires a fast ramp up supply.
>
>
>
> On 11/14/2014 3:03 AM, bremenpl wrote:
>
> Hello there,
> I have a very strange problem with powering up BeagleBone Black (rev
> C) When i try to power it up from some cheap AC adapter it works fine,
> but when I connect to to my labolatory power supply the power LED on board
> is lid for a second and then doesnt power up the MCU and turns off intead.
> I have connected both supplys to osciloscope and they are both stable, the
> laboratory one even more. Why is the power controller on the BeagleBone
> Black refusing to power up the MCU when powered from lab supply? I have no
> idea what is this about. I would aprichiate 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.
> 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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Bremenpl
>
>  --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

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

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

What is the exact circuit that requires a fast ramp?

W dniu 2014-11-14 o 14:48, evilwulfie pisze:

As Gerald has said before, check the ramp up of the power supply.
Some of the lab supplys have slow ramp ups.
Yes they are very stable and VERY good regulation but
the BBB design requires a fast ramp up supply.



On 11/14/2014 3:03 AM, bremenpl wrote:

Hello there,
I have a very strange problem with powering up BeagleBone Black (rev 
C) When i try to power it up from some cheap AC adapter it works 
fine, but when I connect to to my labolatory power supply the power 
LED on board is lid for a second and then doesnt power up the MCU and 
turns off intead. I have connected both supplys to osciloscope and 
they are both stable, the laboratory one even more. Why is the power 
controller on the BeagleBone Black refusing to power up the MCU when 
powered from lab supply? I have no idea what is this about. I would 
aprichiate 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 
.

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 a topic in the 
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
Bremenpl

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

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

[eltodd]

Hey,

I'm trying to match the below modification in my version of libpruio, but 
while compiling I run into the following

ld: pruio.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can 
not be used when making a shared object; recompile with -fPIC

and I'm not sure how to get past it. I -think- that I have the freebasic 
compiler running correctly. Any advice would be welcome.

Thanks,
Michael Todd


On Thursday, November 6, 2014 10:36:04 AM UTC-8, TJF wrote:
>
> Hello Nils,
>
> thanks for the code. I think about including it in the libpruio examples 
> folder, but your main loop is endless and the user cannot abort the 
> program. (Shouldn't the file get closed?) Perhaps I can adapt it a bit.
>
> Regarding the ADC speed I made some further testing and it seems that I 
> mis-interpreted the TRM. The ADC subsystem can sample at least at 200 kS/s. 
> This speed also works for multiple channels. Find an example of four 
> channels at 44.1 kHz in this post 
> .
>  
> An overall sampling rate of 200 kHz was also possible (four channels).
>
> So the limiting in the current libpruio-0.2 is too much on the safe site. 
> If you don't want to wait for the next version, you can adapt the code by 
> yourself (FreeBASIC compiler required). Replace in file pruio_adc.bas in 
> function PruIo.configure(...) the lines
>
>   d *= (Conf->ADC_CLKDIV + 1) * 417 '417 ≈ 100 / 2400 (= 1 GHz / 
> 2.4 MHz)
>   d += 30 ' PRU cycles for restart [GHz]
>   IF Tmr <= d THEN .Errr = @"sample rate too big" : RETURN .Errr
>
> by the following code
>
>   d = (d * (Conf->ADC_CLKDIV + 1) * 1000) \ 24
>   IF Tmr <= d ORELSE Tmr < 5000 THEN _
>.Errr = @"sample rate too big" : RETURN .Errr
>
> You may play a bit with the absolute value 5000. On my BBB the timing is 
> OK up to a frequency of 240 kHz (4165). But this may vary from board to 
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Custom Beaglebone black Audio cape with TLV320AIC3110

[resandevinwebb]

Hi,

I am trying to design a cape with TLV320AIC3110 for Beaglebone black using 
I2c2 and Mcasp0. I have compiled the driver into the kernel and modified 
the device tree. This is my procedure.

ubuntu@arm:~$ uname -r
3.15.10-bone8

1- Driver:
I am using the driver in /sound/soc/codecs/tlc320aic31xx.c
diff --git a/sound/soc/codecs/tlv320aic31xx.c 
b/sound/soc/codecs/tlv320aic31xx.c
index d1929de..1c300a5 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -19,7 +19,7 @@
  * high performance codec which provides a stereo DAC, a mono ADC,
  * and mono/stereo Class-D speaker driver.
  */
-
+#define DEBUG 
 #include 
 #include 
 #include 

2- Edit Kconfig
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index f0e8401..19036e3 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -461,7 +461,8 @@ config SND_SOC_TLV320AIC26
depends on SPI
 
 config SND_SOC_TLV320AIC31XX
-tristate
+tristate "TI TLV320AIC31xx class D codecs"
+   depends on I2C
 
 config SND_SOC_TLV320AIC32X4
tristate


3- ALSA Machine Layer Configuration:

Create a DAI (digital audio interface) Link structure. This should allow a 
specific configuration for the McASP to be called when Linux is directed to 
play audio to the TLV320AIC31XX. For Sitara McASP machine layer driver is 
found at sound/soc/davinci/davinci-evm.c

diff --git a/sound/soc/davinci/davinci-evm.c 
b/sound/soc/davinci/davinci-evm.c
index cab98a5..41db457 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -8,7 +8,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
+#define DEBUG
 #include 
 #include 
 #include 
@@ -98,6 +98,13 @@ static const struct snd_soc_dapm_widget 
aic3x_dapm_widgets[] 
SND_SOC_DAPM_LINE("Line In", NULL),
 };
 
+static const struct snd_soc_dapm_widget aic31xx_dapm_widgets[] = {
+   SND_SOC_DAPM_HP("Headphone Jack", NULL),
+   SND_SOC_DAPM_SPK("Speaker", NULL),
+   SND_SOC_DAPM_MIC("Mic Jack", NULL),
+};
+
+
 /* davinci-evm machine audio_mapnections to the codec pins */
 static const struct snd_soc_dapm_route audio_map[] = {
/* Headphone connected to HPLOUT, HPROUT */
@@ -120,6 +127,7 @@ static const struct snd_soc_dapm_route audio_map[] = {
{"LINE2R", NULL, "Line In"},
 };
 
+
 /* Logic for a aic3x as connected on a davinci-evm */
 static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
 {
@@ -150,6 +158,42 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime 
*rtd)
return 0;
 }
 
+/* Logic for a aic31xx as connected on a davinci-evm */
+static int evm_aic31xx_init (struct snd_soc_pcm_runtime *rtd)
+{
+struct snd_soc_codec *codec = rtd->codec;
+struct snd_soc_dapm_context *dapm = &codec->dapm;
+struct device_node *np = codec->card->dev->of_node;
+int ret;
+
+/* Add davinci-evm specific widgets */
+snd_soc_dapm_new_controls(dapm, aic31xx_dapm_widgets,
+  ARRAY_SIZE(aic31xx_dapm_widgets));
+
+if (np) {
+ret = snd_soc_of_parse_audio_routing(codec->card, 
"ti,audio-rou
+if (ret)
+return ret;
+} 
+/*
+else {
+*/
+/* Set up davinci-evm specific audio path audio_map */
+/*
+snd_soc_dapm_add_routes(&card->dapm, audio_map,
+ARRAY_SIZE(audio_map));
+}
+*/
+/* not connected */
+/*snd_soc_dapm_nc_pin(&codec->dapm, "MONO_LOUT");
+snd_soc_dapm_nc_pin(&codec->dapm, "HPLCOM");
+snd_soc_dapm_nc_pin(&codec->dapm, "HPRCOM");
+*/
+return 0;
+}
+
+
+
 /* davinci-evm digital audio interface glue - connects codec <--> CPU */
 static struct snd_soc_dai_link dm6446_evm_dai = {
.name = "TLV320AIC3X",
@@ -250,6 +294,8 @@ static struct snd_soc_dai_link da850_evm_dai = {
   SND_SOC_DAIFMT_IB_NF,
 };
 
+
+
 /* davinci dm6446 evm audio machine driver */
 /*
  * ASP0 in DM6446 EVM is clocked by U55, as configured by
@@ -343,16 +389,33 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
.stream_name= "AIC3X",
.codec_dai_name = "tlv320aic3x-hifi",
.ops= &evm_ops,
-   .init   = evm_aic3x_init,
+.init   = evm_aic3x_init,
.dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
   SND_SOC_DAIFMT_IB_NF,
 };
+/*Modified evm_dai_tlv320aic3x() for aic3110   */
+static struct snd_soc_dai_link evm_dai_tlv320aic3110 = {
+.name   = "TLV320AIC3110",
+.stream_name= "AIC3110",   /* What should I put here? */
+.codec_dai_name = "tlv320aic31xx-hifi",
+.ops= &evm_ops,
+.init   = evm_aic31xx_init,
+.dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
+   

Re: [beagleboard] Re: BeagleBoard-X15 - seriously? :)

[danesh . petigara]

Thanks for clarifying!

On Thursday, November 13, 2014 1:15:53 PM UTC-8, Gerald wrote:
>
> TI is waiting for approval from the IP owner as to what can be put into 
> the document. This was a way to get it out sooner and not have to wait on 
> the IP owner.
> It will be included in the final release.
>
>
> Gerald
>
>
> On Thu, Nov 13, 2014 at 2:25 PM, > 
> wrote:
>
>> Was checking the AM572x TRM and noticed that the PCIe Controller section 
>> (24.9) is blank. Any particular reason why the information on this block 
>> cannot be shared in the public domain?
>>
>> Thanks
>>
>> On Friday, November 7, 2014 1:05:21 AM UTC-8, lisarden wrote:
>>>
>>> Hey guys!
>>>
>>> BeagleBoard-X15  - 
>>> Are you really going to release such monster? :)
>>>
>>> -- 
>>> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
>>> Company - http://www.linkedin.com/company/mentorel
>>> Facebook - https://www.facebook.com/mentorel.company
>>>  
>>  -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
> http://circuitco.com/support/
>  

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

[beagleboard] How to enable all i2c

[ngoctam121191]

I use I2C-Tools to detect the i2c like:

root@android:/ # i2cdetect 
-l  


i2c-1   i2c OMAP I2C adapterI2C 
adapter
i2c-3   i2c OMAP I2C adapterI2C adapter 

but in beablebone black(ver C), it has 3 i2c, so how to enable all.
please give me some advices

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

[beagleboard] Re: USB hotplugging

[neonsignal]

On Thursday, November 13, 2014 9:50:15 PM UTC+11, Alexander Rössler wrote:
>
> USB hot-plugging is a known issue with the 3.8.x kernels on the BBB. You 
> can try using the latest Jessie release if hot-pluggin is important for you
>

Thanks for the advice - I switched to using the 3.14.17 kernel (still under 
Wheezy), and it solved my USB hotplugging issue (not to mention some hub 
issues I had also encountered).

Glenn

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

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[evilwulfie]

As Gerald has said before, check the ramp up of the power supply.
Some of the lab supplys have slow ramp ups.
Yes they are very stable and VERY good regulation but
the BBB design requires a fast ramp up supply.



On 11/14/2014 3:03 AM, bremenpl wrote:
> Hello there,
> I have a very strange problem with powering up BeagleBone Black (rev
> C) When i try to power it up from some cheap AC adapter it works
> fine, but when I connect to to my labolatory power supply the power
> LED on board is lid for a second and then doesnt power up the MCU and
> turns off intead. I have connected both supplys to osciloscope and
> they are both stable, the laboratory one even more. Why is the power
> controller on the BeagleBone Black refusing to power up the MCU when
> powered from lab supply? I have no idea what is this about. I would
> aprichiate 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
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Leaking memory in kernel 3.8.13bone65 ?

[Micka]

I got my answer :


"A running Linux system will quickly end up allocating all "free" memory to
disk cache. This memory is still free because it can be reclaimed from
cache and given to processes without any delay"

Micka,

Le Fri Nov 14 2014 at 14:04:34, Micka  a écrit :

> HI,
>
>
> I'm working on a beaglebone black kernel 3.8.13bone65 .
>
>
> My problem is that I don't have any program running, but the memory is
> almost full  :
>
> root@beaglebone:~# uname -a
> Linux beaglebone 3.8.13-bone65 #3 SMP Thu Sep 18 09:39:21 CEST 2014 armv7l
> GNU/Linux
>
>
> root@beaglebone:~# free -m
>  total   used   free sharedbuffers cached
> Mem:   496410 85  0 78184
> -/+ buffers/cache:146349
> Swap:0  0  0
>
>
> root@beaglebone:~# ps aux --sort -rss
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> root  1094  0.2  1.4  14760  7576 ?SFeb24   7:48
> /usr/bin/python -O /usr/share/wicd/daemon/monitor.py
> root  1086  0.5  1.3  23880  6924 ?SFeb24  17:35
> /usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
> root   958  0.0  1.0  12484  5360 tty2 Ss+  Feb24   0:00 X
> root   680  0.0  0.6  25416  3300 ?Ssl  Feb24   0:00
> /usr/sbin/console-kit-daemon --no-daemon
> root   681  0.0  0.6  24548  3152 ?Ssl  Feb24   0:00
> /usr/lib/upower/upowerd
> root   868  0.0  0.5  21936  2744 ?Ssl  Feb24   0:00
> /usr/lib/policykit-1/polkitd --no-debug
> root 1  0.0  0.5   4496  2656 ?Ss   Feb24   0:01
> /lib/systemd/systemd
> root  4915  0.0  0.4   7860  2360 ?Ss   22:46   0:00 sshd:
> root@notty
> root  5478  0.0  0.4   7860  2360 ?Ss   23:32   0:00 sshd:
> root@notty
> root  5502  0.3  0.4   7720  2332 ?Ss   23:34   0:01 sshd:
> root@pts/0
> root   676  0.0  0.3   4600  1564 ?Ss   Feb24   0:00
> /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant
> root   203  0.0  0.3   4404  1532 ?Ss   Feb24   0:10
> /lib/systemd/systemd-journald
> root   682  0.0  0.3  28392  1528 ?Ssl  Feb24   0:03
> /usr/sbin/rsyslogd -n -c5
> root  5505  0.0  0.2   2640  1520 pts/0Ss   23:34   0:00 -bash
> avahi  667  0.0  0.2   2760  1432 ?Ss   Feb24   0:00
> avahi-daemon: running [beaglebone.local]
> 101673  0.2  0.2   2716  1424 ?Ss   Feb24   7:15
> /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --sys
> root   225  0.0  0.2   2544  1416 ?Ss   Feb24   0:00
> /sbin/udevd
> root   677  0.0  0.2   2916  1264 ?Ss   Feb24   0:00
> /lib/systemd/systemd-logind
> root   978  0.0  0.2   2540  1084 ?SFeb24   0:00
> /sbin/udevd
> root   979  0.0  0.2   2540  1024 ?SFeb24   0:00
> /sbin/udevd
> root   884  0.0  0.1   5160   968 ?Ss   Feb24   0:00
> /usr/sbin/sshd
> root  5614  0.0  0.1   2484   916 pts/0R+   23:41   0:00 ps aux
> --sort -rss
> root  4918  0.0  0.1   1772   796 ?Ss   22:46   0:00
> /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
> root  5481  0.0  0.1   1772   796 ?Ss   23:32   0:00
> /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
> root   701  0.0  0.1   3344   716 tty1 Ss+  Feb24   0:00
> /sbin/agetty tty1 38400
> root   702  0.0  0.1   3164   712 ttyO0Ss+  Feb24   0:00
> /sbin/agetty -s ttyO0 115200 38400 9600
> root   890  0.0  0.1   3356   704 ?Ss   Feb24   0:01
> /usr/sbin/cron
> root   674  0.0  0.1   1332   684 ?Ss   Feb24   0:00
> /usr/sbin/acpid
> root  1010  0.0  0.1   1780   544 ?Ss   Feb24   0:00
> /usr/sbin/udhcpd -S /etc/udhcpd.conf
> avahi  717  0.0  0.0   2760   500 ?SFeb24   0:00
> avahi-daemon: chroot helper
>
>
> Do you know how can i find out who is using that much of memory ? Do you
> think that it can be the kernel ? the log ?
>
> Micka,
>
>
>
>

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

[beagleboard] Leaking memory in kernel 3.8.13bone65 ?

[Micka]

HI,


I'm working on a beaglebone black kernel 3.8.13bone65 .


My problem is that I don't have any program running, but the memory is
almost full  :

root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone65 #3 SMP Thu Sep 18 09:39:21 CEST 2014 armv7l
GNU/Linux


root@beaglebone:~# free -m
 total   used   free sharedbuffers cached
Mem:   496410 85  0 78184
-/+ buffers/cache:146349
Swap:0  0  0


root@beaglebone:~# ps aux --sort -rss
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root  1094  0.2  1.4  14760  7576 ?SFeb24   7:48
/usr/bin/python -O /usr/share/wicd/daemon/monitor.py
root  1086  0.5  1.3  23880  6924 ?SFeb24  17:35
/usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
root   958  0.0  1.0  12484  5360 tty2 Ss+  Feb24   0:00 X
root   680  0.0  0.6  25416  3300 ?Ssl  Feb24   0:00
/usr/sbin/console-kit-daemon --no-daemon
root   681  0.0  0.6  24548  3152 ?Ssl  Feb24   0:00
/usr/lib/upower/upowerd
root   868  0.0  0.5  21936  2744 ?Ssl  Feb24   0:00
/usr/lib/policykit-1/polkitd --no-debug
root 1  0.0  0.5   4496  2656 ?Ss   Feb24   0:01
/lib/systemd/systemd
root  4915  0.0  0.4   7860  2360 ?Ss   22:46   0:00 sshd:
root@notty
root  5478  0.0  0.4   7860  2360 ?Ss   23:32   0:00 sshd:
root@notty
root  5502  0.3  0.4   7720  2332 ?Ss   23:34   0:01 sshd:
root@pts/0
root   676  0.0  0.3   4600  1564 ?Ss   Feb24   0:00
/sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant
root   203  0.0  0.3   4404  1532 ?Ss   Feb24   0:10
/lib/systemd/systemd-journald
root   682  0.0  0.3  28392  1528 ?Ssl  Feb24   0:03
/usr/sbin/rsyslogd -n -c5
root  5505  0.0  0.2   2640  1520 pts/0Ss   23:34   0:00 -bash
avahi  667  0.0  0.2   2760  1432 ?Ss   Feb24   0:00
avahi-daemon: running [beaglebone.local]
101673  0.2  0.2   2716  1424 ?Ss   Feb24   7:15
/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --sys
root   225  0.0  0.2   2544  1416 ?Ss   Feb24   0:00 /sbin/udevd
root   677  0.0  0.2   2916  1264 ?Ss   Feb24   0:00
/lib/systemd/systemd-logind
root   978  0.0  0.2   2540  1084 ?SFeb24   0:00 /sbin/udevd
root   979  0.0  0.2   2540  1024 ?SFeb24   0:00 /sbin/udevd
root   884  0.0  0.1   5160   968 ?Ss   Feb24   0:00
/usr/sbin/sshd
root  5614  0.0  0.1   2484   916 pts/0R+   23:41   0:00 ps aux
--sort -rss
root  4918  0.0  0.1   1772   796 ?Ss   22:46   0:00
/usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
root  5481  0.0  0.1   1772   796 ?Ss   23:32   0:00
/usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
root   701  0.0  0.1   3344   716 tty1 Ss+  Feb24   0:00
/sbin/agetty tty1 38400
root   702  0.0  0.1   3164   712 ttyO0Ss+  Feb24   0:00
/sbin/agetty -s ttyO0 115200 38400 9600
root   890  0.0  0.1   3356   704 ?Ss   Feb24   0:01
/usr/sbin/cron
root   674  0.0  0.1   1332   684 ?Ss   Feb24   0:00
/usr/sbin/acpid
root  1010  0.0  0.1   1780   544 ?Ss   Feb24   0:00
/usr/sbin/udhcpd -S /etc/udhcpd.conf
avahi  717  0.0  0.0   2760   500 ?SFeb24   0:00
avahi-daemon: chroot helper


Do you know how can i find out who is using that much of memory ? Do you
think that it can be the kernel ? the log ?

Micka,

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

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

I read you post again:
I am plugging a cable that has power already, not using the switch.


Dnia 14 listopada 2014 13:06:11 Gerald Coley  
napisał(a):



Have you tried leaving the power supply on and plug in the cable to the
board or are you using the power switch on the power supply?

Gerald

On Friday, November 14, 2014, bremenpl  wrote:

> Hello there,
> I have a very strange problem with powering up BeagleBone Black (rev
> C) When i try to power it up from some cheap AC adapter it works fine,
> but when I connect to to my labolatory power supply the power LED on board
> is lid for a second and then doesnt power up the MCU and turns off intead.
> I have connected both supplys to osciloscope and they are both stable, the
> laboratory one even more. Why is the power controller on the BeagleBone
> Black refusing to power up the MCU when powered from lab supply? I have no
> idea what is this about. I would aprichiate 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
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


--
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the 
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Bremenpl]

I just plug the power and the board normally should turn on but it doesnt. 
I then press the pwr btn but the result is the same as if i plugged the 
power supply in.



Dnia 14 listopada 2014 13:06:11 Gerald Coley  
napisał(a):



Have you tried leaving the power supply on and plug in the cable to the
board or are you using the power switch on the power supply?

Gerald

On Friday, November 14, 2014, bremenpl  wrote:

> Hello there,
> I have a very strange problem with powering up BeagleBone Black (rev
> C) When i try to power it up from some cheap AC adapter it works fine,
> but when I connect to to my labolatory power supply the power LED on board
> is lid for a second and then doesnt power up the MCU and turns off intead.
> I have connected both supplys to osciloscope and they are both stable, the
> laboratory one even more. Why is the power controller on the BeagleBone
> Black refusing to power up the MCU when powered from lab supply? I have no
> idea what is this about. I would aprichiate 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
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


--
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the 
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/xRPC_39ju9Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Labolatory power supply fails to power up BeagleBone Black

[Gerald Coley]

Have you tried leaving the power supply on and plug in the cable to the
board or are you using the power switch on the power supply?

Gerald

On Friday, November 14, 2014, bremenpl  wrote:

> Hello there,
> I have a very strange problem with powering up BeagleBone Black (rev
> C) When i try to power it up from some cheap AC adapter it works fine,
> but when I connect to to my labolatory power supply the power LED on board
> is lid for a second and then doesnt power up the MCU and turns off intead.
> I have connected both supplys to osciloscope and they are both stable, the
> laboratory one even more. Why is the power controller on the BeagleBone
> Black refusing to power up the MCU when powered from lab supply? I have no
> idea what is this about. I would aprichiate 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
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

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

Re: [beagleboard] Re: Coding with C/C++ directly on Beaglebone, via IDE?

[David Goodenough]

On Friday 14 November 2014 03:03:32 csu...@idapl.in wrote:
> can anyone help me in how to setup codelite on beaglebone directy
> 
> thanks in advance
> 
> sumik
If you are running Debian:-

apt-get install codelite codelite-plugins

You will either need to be root to do this or use sudo if that is set up.

David

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

[beagleboard] Re: Only able to read 0x0 or FF with spidev...

[lambertarthur22]

Hi Jan,

Ok so your first advice was really good. I can see that I was not able to 
run a simple loopback between the D1/D0 pin on the board; So I conclude 
that the problem come from the wire. I was pretty sure about the 
configuration and software part.

So I finally change the jumper/wire used to rely the two pins and then 
miracle

root@beaglebone:~# ./spidev_test -D /dev/spidev1.0 
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)

FF FF FF FF FF FF 
40 00 00 00 00 95 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
DE AD BE EF BA AD 
F0 0D 

So it was definitely a connexion issue. So Now just need to come back with 
my original setup to test my previous code to communicate between ads1299 
and the Beaglebone black. So yes I move one ! Lets find the next issue !

Thanks again Jan,
Arthur.


Le mercredi 12 novembre 2014 22:57:40 UTC+1, janszyma...@gmail.com a écrit :
>
> Hi Arthur,
>
> BBB is a very time consuming hobby.
> Take it ease, relax, go for a walk and when you return, try:
>
> 1) try your project as root 
> if no luck follow my (working) path
>
> 2) Try to repeat my settings and see if it works for you.
> I wasn't able to build the original Linux spidev_test, so...
>
> What I have is:
>  
> root@beaglebone:~# uname -a
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
> GNU/Linux
>
> Following the instruction from here 
> http://www.nagavenkat.adurthi.com/2014/02/spi-communication-beaglebone-black-as-master-to-arduino-as-slave/
>  
> I created SPI-4SS-00A0.dts and compiled it into SPI-4SS-00A0.dts following 
> exactly the instruction
>
> By doing that you should have in /sys/devices/bone_capemgr.9/slots
>
>  0: 54:PF--- 
>  1: 55:PF--- 
>  2: 56:PF--- 
>  3: 57:PF--- 
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  8: ff:P-O-L Override Board Name,00A0,Override Manuf,SPI-4SS
>
> To test it I obtained and created files in /opt/test/test2 as attached:
> build
> SimpleGPIO.cpp - from Derek Molloy 
> https://github.com/derekmolloy/beaglebone/blob/master/SimpleGPIO.cpp
> SimpleGPIO.h - from Derek Molloy 
> https://github.com/derekmolloy/beaglebone/blob/master/SimpleGPIO.h 
> test2.cpp - mine main file
>
> unzip attached and compile 
>
> root@beaglebone:/opt/test/test2# ./build
> Building test2 - J.Sz.
> root@beaglebone:/opt/test/test2#
>  
> then run (have P9-18 and P9-21 connected as loopback)
>
> root@beaglebone:/opt/test/test2# ./test2
> Initialize SS pins for SPI
> Initialize SPI
> SPI transfer
> rx = 30 31 32 33 34 35 36 37
> rx = 31 32
> rx = 33 34
> rx = 35 36
> rx = 37 38
> rx = 30 31 32 33 34 35 36 37
> ...
>
> press CTRL-C to terminate or let it run and observe with a scope all SPI0 
> signals
>
> Hope this will help
>
> Jan
>
> Sorry, I don't see how to insert a file so:
> build is:
>
> #!/bin/bash 
> echo "Building test2 - J.Sz." 
> g++ test2.cpp SimpleGPIO.cpp -o test2
>
> test2.cpp is
>
> //#ifndef SPICOMM_H_
> //#define SPICOMM_H_
>
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include "SimpleGPIO.h"
> #include 
> #include 
> #include "SimpleGPIO.h"
>
> using namespace std;
>
> // example functions from 
> http://www.nagavenkat.adurthi.com/2014/02/spi-communication-beaglebone-black-as-master-to-arduino-as-slave/
>
> #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
>
> static void pabort(const char *s)
> {
>  perror(s);
>  abort();
> }
>
>
> //4 SS pins for 4 SPI devices
> void init_motor_spi_ss(int gpio1,int gpio2,int gpio3,int gpio4){
> //export the pins. I have used then pins described in the table above
>  gpio_export(gpio1);
>  gpio_export(gpio2);
>  gpio_export(gpio3);
>  gpio_export(gpio4);
>
> // set them as High. The SS pins should be high when idle(no commuication)
>
>  gpio_set_dir(gpio1, OUTPUT_PIN);
>  gpio_set_dir(gpio2, OUTPUT_PIN);
>  gpio_set_dir(gpio3, OUTPUT_PIN);
>  gpio_set_dir(gpio4, OUTPUT_PIN);
>
> gpio_set_value(gpio1, HIGH);
>  gpio_set_value(gpio2, HIGH);
>  gpio_set_value(gpio3, HIGH);
>  gpio_set_value(gpio4, HIGH);
>
> }
>
> static const char *device = "/dev/spidev1.0";  // this is when SPI0 was 
> enabled. change it when SPI1 is enabled
> static uint8_t mode=0;  //this mode works well for me
> static uint8_t bits = 8; //arduino accepts 8 bits at once
> //static uint32_t speed = 100; //1MHz speed
> static uint32_t speed = 100; //2MHz speed
> static uint16_t delay=0;
>
> static void init_spi(void)
> {
>  int fd;
>  int ret = 0;
>
>  fd = open(device, O_RDWR);
>  if (fd < 0)
>  pabort("can't open device");
>
> /*
>  * spi mode
>  */
>  ret = ioctl(fd, SPI_IOC_WR_MODE, &mode);
>  if (ret == -1)
>  pabort("can't set spi mode");
> ret = ioctl(fd, SPI_IOC_RD_MODE, &mode);
>  if (ret == -1)
>  pabort("can't get spi mode");
>
> /*
>  * bits per word
>  */
>  ret = ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, &bits);
>  if (ret == -1)
>  pabort("can't set bit

[beagleboard] Re: Coding with C/C++ directly on Beaglebone, via IDE?

[csumik]

can anyone help me in how to setup codelite on beaglebone directy 

thanks in advance 

sumik
 

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

[beagleboard] Labolatory power supply fails to power up BeagleBone Black

[bremenpl]

Hello there,
I have a very strange problem with powering up BeagleBone Black (rev C) 
When i try to power it up from some cheap AC adapter it works fine, but 
when I connect to to my labolatory power supply the power LED on board is 
lid for a second and then doesnt power up the MCU and turns off intead. I 
have connected both supplys to osciloscope and they are both stable, the 
laboratory one even more. Why is the power controller on the BeagleBone 
Black refusing to power up the MCU when powered from lab supply? I have no 
idea what is this about. I would aprichiate 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB kernel 3.8.13 cross compilation issues.

[Gadre Nayan]

Hello guys,

I have started using BBB recently, And I need to add my own GPIO drivers to 
the kernel.

I have update the angstrom image from the official beagleboard site using 
Windows. I have successfully booted the kernel and tested it using the 
Browser start.html LED script. So far so good.

I checked my kernel version installed which is 3.8.13. So i got the linux 
Source from  "https://github.com/koenkooi/linux/tree/3.8-for-panto-rebase";.

Then I did the usual  and  on my Ubuntu machine as host. I get the following 
error:

*root@gadre-Inspiron-1525:/home/gadre/Desktop/BBB/linux-3.8# make ARCH=arm 
CROSS_COMPILE=arm-linux-gnueabi- -j2*
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  LD  arch/arm/kernel/built-in.o
arch/arm/kernel/devtree.o: In function `early_init_dt_add_memory_arch':
/home/gadre/Desktop/BBB/linux-3.8/include/linux/of.h:777: multiple 
definition of `of_free_overlay_info'
arch/arm/kernel/smp_twd.o:/home/gadre/Desktop/BBB/linux-3.8/include/linux/of.h:777:
 
first defined here
arch/arm/kernel/perf_event_cpu.o: In function `of_free_overlay_info':
/home/gadre/Desktop/BBB/linux-3.8/include/linux/of.h:777: multiple 
definition of `of_free_overlay_info'
arch/arm/kernel/smp_twd.o:/home/gadre/Desktop/BBB/linux-3.8/include/linux/of.h:777:
 
first defined here
arch/arm/kernel/topology.o: In function `of_free_overlay_info':
/home/gadre/Desktop/BBB/linux-3.8/include/linux/of.h:777: multiple 
definition of `of_free_overlay_info'
arch/arm/kernel/smp_twd.o:/home/gadre/Desktop/BBB/linux-3.8/include/linux/of.h:777:
 
first defined here
make[1]: *** [arch/arm/kernel/built-in.o] Error 1
make: *** [arch/arm/kernel] Error 2
make: *** Waiting for unfinished jobs

What should I do. Please suggest 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.
For more options, visit https://groups.google.com/d/optout.